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PREFACE 


This  report  describes  the  work  performed,  the  results  obtained,  and  the 
conclusions  reached  during  the  Common  Ada  Missile  Packages  (CAMP)  contract 
(F08635-B4-C-02B0) .  This  work  was  performed  by  the  Computer  Systems  & 
Software  Engineering  Department  of  the  McOonnell  Oouglas  Astronautics 
Company,  St.  Louis,  Missouri  (MOAC-STL)  and  was  sponsored  by  the  United 
States  Air  Force  Armament  Laboratory  (FXG)  at  Eg  1 1 n  Air  Force  Base, 

Florida.  This  contract  was  performed  between  September  1984  and  September 
1985. 

The  MOAC-STL  CAMP  program  manager  was  Dr.  Daniel  G.  McNIcholl  (McOonnell 
Douglas  Astronautics  Company,  Computer  Systems  and  Software  Engineering 
Department,  P.0.  Box  516,  St.  Louis,  Mo.  63166)  and  the  AFATL  CAMP  program 
manager  was  Christine  M.  Anderson  (Air  Force  Armament  Laboratory, 
Aeromechanics  Division,  Guidance  and  Control  Branch,  Eglln  Air  Force  Base, 
Florida  32542). 

This  report  consists  of  three  volumes.  Volume  I  contains  overview 
material  and  the  results  of  the  CAMP  commonality  study.  Volume  II  contains 
the  results  from  the  CAMP  automated  parts  engineering  study.  Volume  III 
contains  the  rationale  for  the  CAMP  parts. 

Commercial  hardware  and  software  products  mentioned  In  this  report  are 
sometimes  Identified  by  manufacturer  or  brand  name.  Such  mention  Is 
necessary  for  an  understanding  of  the  R  &  0  effort,  but  does  not  constitute 
endorsement  of  these  Items  by  the  U.S.  Government 
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SECTION  I 
INTRODUCTION 


This  volume  contains  the  results  of  the  work  performed  on  CAMP  In  the 
development  of  a  software  parts  catalog  and  In  the  design  of  a  prototype 
software  parts  composition  system. 

Section  II  describes  the  results  of  the  CAMP  software  parts  cataloging 
study  and  the  cataloging  scheme  recommended  for  CAMP.  The  goal  of  the 
software  cataloging  task  was  to  develop  a  method  of  describing  and  managing 
software  parts  to  Increase  the  productivity  of  the  parts  user.  In  addition 
to  providing  the  structure  for  a  textual  catalog,  the  cataloging  scheme 
developed  on -CAMP  Is  suitable  for  automation.  Appendices  A  through  C  present 
more  detailed  Information  on  the  CAMP  cataloging  scheme. 

Section  III  contains  the  results  of  the  CAMP  software  generation  study 
and  presents  our  view  of  the  functionality  of  a  software  parts  composition 
system.  Although  our  major  area  of  study  was  the  automatic  generation  of 
software  using  parts,  this  examination  Included  an  Investigation  of  software 
generation  systems  which  did  not  handle  parts. 

Section  IV  discusses  the  role  of  an  expert  system  In  the  construction  of 
a  software  Parts  Composition  System  (PCS).  The  prototype  software  parts 
composition  system  we  designed  during  CAMP  was  based  on  incorporating  all 
functions  within  an  expert  system  to  maximize  the  sharing  of  data  between 
components  of  the  PCS. 

Section  V  describes  the  particular  expert  system  tool,  the  Automated 
Reasoning  Tool  (ART),  used  on  CAMP  and  discusses  Its  applicability  In  the 
software  parts  composition  system  application.  This  tool  was  used  to 
construct  a  proof-of  concept  Implementation  of  a  schematic  part.  Appendix  0 
contains  a  description  of  this  schematic  part  constructor. 

Section  VI  discusses  the  major  conclusions  of  the  software  cataloging  and 
software  parts  composition  system  studies. 
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1 .  INTRODUCTION 

The  objective  of  this  portion  of  the  CAMP  study  was  the  development  of  a 
procedure  to  facilitate  storage  and  retrieval  of  software  parts  for  use  on 
other  projects.  To  achieve  this  objective,  an  Ada  parts  cataloging  scheme 
was  developed  which  provides  a  means  for  organizing.  Indexing,  describing, 
and  referencing  these  parts. 

In  Paragraph  2  existing  software  cataloging  schemes  are  reviewed.  Major 
Issues  related  to  software  parts  description  are  discussed  In  Paragraph  3.  A 
detailed  description  of  the  cataloging  scheme  that  was  developed  Is  provided 
In  Paragraph  4.  In  addition  to  developing  the  cataloging  scheme,  the 
documentation  required  to  support  It  has  also  been  Identified  (see  Paragraph 
5).  Paragraph  6  contains  recommendations  for  the  organizational  structure 
needed  to  support  the  Implementation  and  use  of  this  scheme. 

2.  REVIEW 

For  many  years  people  have  advocated  the  use  of  existing  software  parts 
as  a  way  to  reduce  the  cost  of  software  development  and  maintenance. 

Although  there  Is  currently  a  great  deal  of  research  being  conducted  In  this 
area,  significant  Inroads  have  not  been  made  In  the  workplace;  notable 
exceptions  Include  Raytheon  Missile  Systems  (References  1  and  2),  and  The 
Hartford  Insurance  Group  (References  3  and  4),  which  have  achieved  a 
significant  level  of  reuse  In  their  business  data  processing  departments. 

Reuse  of  software  has  been  successful  In  the  area  of  mathematical  and 
statistical  packages  such  as  the  standard  routines  (e.g.,  sine,  cosine) 


usually  supplied  by  compiler  vendors,  or  the  International  Hath  and 
Statistical  Library  (IHSL)  and  Numerical  Algorithms  Group,  Inc.  (NAG) 
software  libraries.  The  primary  reason  for  this  success  Is  that  users 
understand  the  functioning  of  the  routines  and  have  confidence  In  their 
quality,  for  Instance,  In  the  case  of  the  IHSL,  the  routines  undergo 
extensive  testing;  they  are  developed  with  strict  adherence  to  standards;  the 
code  Is  robust,  efficient,  and  accurate;  technical  support  Is  provided;  and 
the  documentation  (l.e.,  the  catalog)  Is  comprehensive  and  standardized. 

One  of  the  most  significant  reasons  for  the  failure  of  many  past 
reusability  efforts  Is  that  a  disproportionate  emphasis  has  been  placed  on 
development  of  software  components,  while  little  or  no  effort  was  expended  on 
developing  a  method  for  describing  and  Identifying  available  parts. 

As  a  prelude  to  developing  an  Ada  parts  catalog,  existing  catalogs, 
cataloging  standards,  and  descriptive  techniques  were  examined.  On-going 
research  efforts  in  software  descriptive  techniques  were  also  reviewed.  None 
of  the  catalogs,  techniques,  and  standards  reviewed  pertained  specifically  to 
Ada  (some  did  not  even  pertain  specifically  to  software),  but  they  provided 
useful  background  and  Insight  Into  what  Is  required  of  an  Ada  parts  catalog. 

A  survey  of  our  findings  follows. 

a.  Catalog  Standards 

Of  the  standards  reviewed,  those  that  had  the  greatest  applicability 
to  this  task  were  the  ones  dealing  with  computer  program  abstracts.  These 
were  useful  In  determining  the  attributes  and  level  of  support  necessary  to 
develop  a  viable  Ada  parts  catalog. 

One  such  standard  was  developed  by  the  National  Bureau  of  Standards 
(Reference  S) ;  it  was  Intended  to  be  applicable  to  all  programs  developed  or 
acquired  by  Federal  departments  and  agencies.  In  this  scheme,  an  abstract 
provides  a  synopsis  of  capabilities,  environmental  requirements,  and  other 
relevant  Information  that  can  assist  a  user  In  determining  the  functionality 
and  appropriateness  of  a  particular  program. 

The  American  National  Standards  Institute  has  also  developed  a 
standard  for  computer  program  abstracts--ANSI  X3. 88-1981  (Reference  6).  In 
addition  to  the  usual  Items  (l.e.,  name,  date,  contact),  the  standard 
recommends  the  Inclusion  of  a  category  field,  keywords,  program  status  within 
the  lifecycle  (e.g.,  requirements  definition  phase.  In  development. 


operational),  and  assumptions  and  limitations  (e.g.,  assumptions  about  the 
form  and  range  of  the  Input  data). 

b.  Existing  Software  Catalogs 

Although  there  are  a  number  of  software  catalogs  In  existence  today, 
many  use  basically  the  same  attributes  ( 1 . e . ,  name,  id,  abstract,  etc.)  to 
describe  the  software  parts..  In  the  summaries  that  follow,  the  features  of 
existing  catalogs  that  may  be  of  particular  interest  in  developing  an  Ada 
missile  parts  catalog  are  highlighted. 

The  Oata  and  Analysis  Center  for  Software  (DACS)  (Reference  7) 
software  catalog  makes  use  of  a  software  engineering  thesaurus  to  determine 
the  proper  classification  of  a  software  part  both  at  the  time  of  cataloging 
and  at  the  time  of  retrieval.  The  thesaurus  contains  a  listing  of  major 
areas,  called  cluster  terms,  and  separate  listings  of  subjects  within  the 
major  area  (e.g.,  HOOELS  Is  a  major  topic  area  that  Is  found  In  the  list  of 
cluster  terms;  listed  separately  under  MODELS,  the  user  finds  the  field 
further  subdivided  into  AVAILABILITY  HOOELS,  BEHAVIOR  MOOELS,  RELIABILITY 
HOOELS,  etc.).  The  Individual  subject  Items  may  be  further  decomposed. 
Attributes  not  found  In  most  other  catalogs  examined  include  stage  of 
development,  purpose  of  development,  target  computer,  documentation,  and 
references . 

The  National  Technical  Information  Service  (NTIS)  (Reference  8) 
utilizes  a  standard  form  to  collect  data  for  each  software  part  that  will 
come  under  NTIS  control.  The  parts  are  classified  by  category;  there  are  40 
major  categories  (e.g.,  Aeronautics  and  Aerodynamics,  Astronomy  and 
Astrophysics,  Computers,  Control,  and  Information  Theory),  and  34? 
subcategories.  A  subject  classification  booklet  (Reference  9)  is  used  to 
categorize  incoming  software,  and  to  assist  the  user  In  locating  cataloged 
software.  Each  category  Is  given  together  with  the  titles  of  all  of  Its 
subcategories  (e.g.,  within  Computers,  Information,  and  Control  Theory  there 
are  subcategories  such  as  Computer  Hardware,  Computer  Software,  Control 
Systems  and  Control  Theory,  Information  Processing  Standards).  Each 
subcategory  Is  presented  with  a  listing  of  the  subject  areas  covered  by  that 
subcategory  (e.g.,  within  Computer  Software  are  the  subjects  Computer 
Programming,  Programming  Languages,  Compilers,  etc.);  a  cross  reference  to 
related  sections  Is  also  provided. 
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Ihe  NTIS  catalog  entries  are  not  characterized  by  any  unique 
Information;  but  the  catalog  does  have  multiple  Indices  that  allow  access  via 
a  number  of  different  keys.  The  entries  are  Indexed  by  subject  (keyword, 
title.  Id),  producing  agency  (agency  name  and  location,  agency  id,  title, 
product  number,  id).  Id  number  (either  NTIS  Id  or  originating  agency  Id, 
title),  hardware  (entries  are  In  alphanumeric  order  by  hardware  type),  and 
language  (alphanumeric  order  by  source  language). 

The  IMSL  (International  Math  and  Statistical  Library)  Catalog 
(Reference  10)  consists  of  mathematical  and  statistical  routines,  and  has 
gained  widespread  acceptance  and  use  because  of  the  consistent  quality  of  the 
routines.  All  modules  conform  to  established  coding  and  documentation 
standards,  and  contain  both  In-line  and  external  documentation.  The 
algorithms  are  categorized  by  the  area  of  mathematics  or  statistics  to  which 
they  apply,  and  the  categories  are  alphabetized  and  organized  Into  chapters 
In  the  documentation.  The  routines  are  kept  alphabetically  within  category. 
Within  each  documentation  chapter  there  Is  a  quick  reference  guide  to  the 
purpose  of  each  routine. 

For  each  category,  modules  are  described  by  the  following 
Information:  routine  name  (label),  brief  statement  of  purpose, 
prec is  lon/hardware,  and  other  required  IMSL  routines.  Documentation  for  each 
routine  contains  routine  name,  purpose,  call  line,  arguments  (argument  name; 
type;  usage,  l.e.,  input.  Input-output,  output,  work  arrays,  error 
parameters),  precision/hardware,  required  IMSL  routines,  notation,  remarks, 
algorithm,  an  example,  and  optionally,  notes  and  accuracy. 

The  Numerical  Algorithms  Group,  Inc.  (NAG)  (Reference  11)  has  a 
library  of  subroutines  for  mainframes  and  a  small  package  of  routines  for  the 
personal  computer.  The  documentation  provided  for  the  routines  Is  available 
both  In  hard  copy  form  and  on-line.  As  with  the  IMSL  routines,  extensive, 
standardized  documentation  Is  provided,  and  the  routines  go  through  an 
extensive  validation  and  certification  process  before  being  released.  Naming 
conventions  for  the  routines  are  strictly  adhered  to;  this  Is  Important  In 
Increasing  readability.  Updates  to  the  collection  of  routines  are  published 
well  In  advance  of  the  effective  date  in  order  to  allow  users  time  to 
accommodate  these  changes.  The  routines  are  supported  on  a  wide  range  of 
hardware. 


The  Collected  Algorithms  of  CACM  (Reference  12)  provide  extensive 
certification  Information  for  each  algorithm.  This  Includes  'certified  by' 
Information,  explanatory  remarks,  test  procedures,  results,  and  comments. 

Some  other  catalogs  examined  Include  the  Micro  Software  Report 
(Reference  13),  and  the  International  Computer  Programs  Software  Directory 
(Reference  14) . 

c.  Descriptive  Techniques 

The  Naval  Research  Laboratory,  as  part  of  Its  Software  Cost 
Reduction  Project  (References  15  and  16),  developed  a  module  descriptive 
technique  for  software  parts.  Reusability  was  specifically  addressed  In  this 
project.  The  researchers  determined  that  reusability  Is  promoted  by 
well  defined  and  we  1 1 -documented  software.  Information  hiding  and  data 
abstraction  are  two  techniques  that  were  used  to  achieve  this  goal.  An 
abstract  Interface  specification  technique  was  developed  to  allow  Interfaces 
to  be  specified  without  requiring  Internal  details.  Modules  were  designed  to 
be  flexible  ( 1 . e . ,  easily  modifiable)  rather  than  general.  Ada,  through  Its 
package  facility,  provides  many  of  the  features  desired  by  the  researchers  on 
the  Software  Cost  Reduction  project. 

Much  attention  was  given  to  documentation  and  the  form  It  should 
take.  Module  documentation  Is  precise  and  detailed;  It  Is  collected  Into 
module  guides  that  serve  as  a  software  catalog.  The  documentation  explains 
how  requirements  are  allocated  among  the  modules,  and  defines  the  scope  and 
contents  of  Individual  design  documents.  A  precise  abstract  Is  also  provided. 

3.  ISSUES 

Three  major  categories  of  Issues  arose  during  the  Investigation  of 
cataloging  Ada  missile  software  parts.  These  Issues  address  the  following 
areas:  the  cataloging  scheme,  the  cataloging  mechanism,  and  organizational 
requirements.  These  areas  are  not  Independent  of  each  other  and  the 
Interdependencies  will  be  pointed  out  In  the  discussion  that  follows. 
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a.  The  Cataloging  Scheme 


Reuse  of  softw  °  parts  can  be  Implemented  at  a  number  of  different 
levels.  Reusability  can  be  defined  as  reuse  of  analysis  (e.g.,  systems 
analysis,  domain  analysis),  reuse  of  design,  or  reuse  of  code.  The 
Implementation  level  affects  both  the  structure  of  a  parts  catalog  { 1 . e . ,  the 
attributes  needed  to  describe  the  part),  and  the  organlzat lonal  and 
procedural  requirements  needed  to  support  the  use  of  such  a  catalog.  There 
are  several  views  as  to  appropriate  level  at  which  reuse  should  take 
place.  For  example.  Neighbors  (Reference  17)  Indicates  that  to  be 
meaningful,  reuse  should  encompass  analysis  and  design  In  addition  to  code. 

A  number  of  researchers,  have  pursued  the  Idea  of  parts  as  software 
modules  (e.g..  mathematical  and  statistical  routines,  or  special  function 
modules  such  as  data  conversion  routines).  The  Issue  then  arises  as  to 
whether  a  part  Is  reused  only  If  It  Is  taken  'as  Is'  and  used  In  another 
application,  or  if  It  can  still  be  considered  to  be  reused  If  it  undergoes  a 
series  of  transformations  or  modifications  before  It  can  be  used  elsewhere. 

It  has  also  been  suggested  that  parts  consist  of  code  templates  that  can  be 
filled  in  by  the  user.  A  combination  of  approaches  has  proven  successful  In 
several  appl Icat Ions ,  e.g.,  The  Hartford  Insurance  Company  (Reference  <), 
Raytheon  Missile  Systems  (Reference  1). 

The  effectiveness  of  a  parts  catalog  Is  heavily  dependent  upon  the 
selection  of  attributes  that  will  be  kept  for  each  part.  If  the  catalog 
entry  does  not  contain  sufficient  Information  for  a  user  to  determine,  either 
manual  ly  or  via  an  automated  system,  the  appropriateness  of  a  particular 
part,  reuse  of  existing  parts  becomes  virtually  Impossible. 

It  Is  Inevitable  that  eventually  there  will  be  several  parts  In  the 
catalog  that  appear  similar  In  functionality  but  whose  Internals  result  In 
quite  different  execution  or  storage  efficiency.  The  catalog  must  contain 
attributes  that  enable  a  user  to  differentiate  between  these  parts,  or  there 
must  be  an  automated  means  of  determining  the  appropriate  part  for  the  user. 
Lack  of  an  efficient  means  of  differentiating  between  parts  can  lead  to  user 
dissatisfaction  and  a  failure  of  the  reusability  effort. 


7 


b.  The  Cataloging  Mechanism 


The  presentation  of  catalog  Information  to  the  user  can  have  a 
bearing  on  the  success  of  the  parts  catalog.  The  Information  can,  of  course, 
be  presented  textually.  Graphical  representation  of  a  part  may  be  of  value 
In  clarifying  the  part's  definition,  and  thus  help  the  user  to  select  the 
appropriate  part.  There  are  several  different  graphical  representation 
methods  that  could  be  used;  they  are  summarized  In  Figure  1. 

The  technology  requirements  for  the  user  Interface  techniques  must 
be  considered  when  determining  the  feasibility  of  any  particular  system.  For 
example,  database  technology  and  query  language  Interfaces  are  well  developed 
areas  In  computer  science,  but  graphical  and  natural  language  Interfaces  are 
still  In  the  early  stages  of  practical  development. 

To  gain  acceptance  and  use,  a  parts  catalog  must  provide  adequate 
user  support.  It  must  be  well  documented  and  easy  to  use  for  both  novice  and 
experienced  users.  It  must  provide  a  reasonably  fast  response  to  Inquiries; 
users  become  frustrated  with  slow,  cumbersome  systems.  It  must  also  provide 
some  form  of  access  control,  although  this  would  not  necessarily  meet  000 
security  requirements  for  trusted  systems;  research  In  this  area  Is  beyond 
the  scope  of  this  project. 


•  BUHR-  OR  BOOCH-GRAMS  OR  AN  ADAPTATION 

•  FLOW  OtAGRAMS 

•  BEFORE/AFTER  OIAGRAMS  THAT  OEPICT  THE  CHANGES 
TO  THE  OATA  STRUCTURE 

Figure  1.  Graphical  Representation  Methods 


c.  Organizational  Requirements 

One  of  the  most  Important  organizational  Issues  surrounding  a  parts 
catalog  Is  who  will  mandate  Its  development  and  use.  Previous  studies  have 
recommended  the  establishment  of  a  catalog  and  library  of  parts,  but  without 
the  authority  to  enforce  such  a  recommendation,  reuse  of  software 
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parts  has  not  become  a  reality.  Reuse  of  existing  parts »requ1 res  discipline 
on  the  part  of  software  developers;  until  the  benefits  of  reuse  of  parts 
become  obvious  to  all  Involved,  there  must  be  a  means  of  enforcing  that 
dlsclpl Ine. 

The  scope  Issue  must  be  addressed  In  both  the  macroscopic  and 
microscopic  sense.  The  macroscopic  view  addresses  the  applicability  of  a 
parts  catalog  to  an  organization,  i.e.,  the  catalog  can  have  an  Inter -company 
scope  (e.g.,  the  catalog  .ay  contain  Ada  missile  software  parts  developed  by 
all  Air  Force  missile  untractors)  or  Intra  company  scope  (e.g.,  the  catalog 
may  contain  Ada  missile  software  parts  developed  only  by  McDonnell  Douglas). 

The  microscopic  view  addresses  the  domain  of  the  catalog  (e.g.,  the 
domain  could  be  very  broad  and  Include  all  Air  Force  Ada  software  development 
projects,  or  It  could  be  narrow  and  Include  only  Ada  missile  flight 
software).  With  respect  to  the  microscopic  view  of  scope,  a  decision  must  be 
made  whether  to  have  a  single  library,  or  to  have  several  libraries  based  on 
the  application  or  task  area. 

The  organizational  applicability  of  the  catalog  (I.e.,  Is  It 
Inter -company  or  Intra-company),  affects  several  aspects  of  the  catalog 
development  and  maintenance.  For  Instance,  standards  become  very  Important 
when  parts  from  different  developers  are  cataloged  together,  but  It  Is  easier 
to  establish  standards  within  a  single  company  than  across  all  Air  Force 
contractors.  Additionally,  certain  entries  In  the  catalog  should  contain 
different  levels  of  Information  depending  on  the  catalog's  scope.  For 
example.  Information  on  the  developer  would  vary  depending  upon  the  scope  of 
the  catalog.  If  the  catalog  Is  Intra  company.  Information  about  the 
Indlvldual(s)  actually  Involved  In  the  development  may  be  of  use,  whereas  If 
the  catalog  Is  Inter -company ,  merely  Identifying  the  company  performing  the 
development  Is  probably  sufficient.  Additionally,  If  the  catalog  Is 
Intercompany,  the  question  of  proprietary  rights  may  become  an  Issue. 

Procedures  for  maintenance  must  be  established  prior  to  the 
Implementation  of  a  parts  catalog.  Guidelines  are  needed  for  the  addition 
and  removal  of  Items  from  the  catalog.  A  consistent  classification  scheme 
should  be  developed  and  enforced  when  a  part  Is  added  to  the  catalog. 

Security  controls  must  be  Implemented  to  prohibit  unauthorized  access  to  both 
catalog  entries  and  to  the  parts  they  Identify.  There  must  be  a  way  to 
ensure  that  all  required  Information  Is  provided  with  a  part  when  It  enters 
the  catalog  system. 
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Although  there  may  be  a  way  of  differentiating  among  parts  that 
appear  similar,  an  attempt  should  be  made  to  limit  their  proliferation. 
Confronted  by  too  many  choices,  a  user  may  find  It  simpler  to  develop  a  part 
from  scratch  rather  than  wade  through  the  descriptions  of  existing  parts. 
This  problem  can  be  ameliorated  by  the  Imposition  of  procedural  controls  on 
the  maintenance  of  the  parts  catalog  (l.e.,  additions  to  the  parts  catalog 
should  follow  a  standardized  and  carefully  monitored  procedure). 

As  mentioned  earlier,  quality  assurance  (QA)  Is  essential  to  the 
success  of  reusable  parts.  The  exact  nature  of  the  QA  structure  Is  at  least 
partially  dependent  upon  the  scope  of  the  catalog. 

4.  CATALOG  DEFINITION 

The  purpose  of  a  software  parts  catalog  Is  to  facilitate  reuse  of 
existing  software  parts  by  providing  a  mechanism  for  rapidly  Identifying 
relevant  parts  to  a  software  developer.  To  that  end,  the  software  parts 
catalog  must  contain  sufficient  Information  to  permit  selection  of 
components,  but  not  so  much  Information  that  It  Is  cumbersome  to  use  This 
requires  careful  selection  of  attributes  for  Inclusion  In  the  catalog. 

The  Investigators  have  developed  a  set  of  attributes  to  describe  each 
catalog  entry  which  provide  the  catalog  user  with  sufficient  but  not 
overwhelming  Information  about  Individual  software  parts.  Figure  2 
summarizes  these  attributes.  Each  of  these  attributes  Is  discussed  In 
greater  detail  In  Appendix  A.  Figure  3  graphically  depicts  the  flow  of 
Information  Into  and  from  the  parts  catalog  system. 

HDAC-STl  developed  a  prototype  Ada  parts  catalog  as  a  proof  of  concept. 

TH 

The  catalog  was  developed  using  a  relational  database  system  (ORACLE  )  on 
a  VAX  11/780.  A  description  of  this  catalog  Is  contained  In  Appendix  C. 


PART  ID 

REVISION  ID 

VERSION 

NAME 

ABSTRACT 

CATEGORY 

TYPE 

LEVEL 

CLASS 

INLINE 

OPERATION 

PARAMETER  NAME 

KEYWORDS 

DATE  CATALOGED 

OEVELOPED  BY 

OEVELOPED  FOR 

DEVELOPMENT  STATUS 

VERIFICATION  STATUS 

CATALOG  UNITS  WITHED 

W1THING  UNITS 

USAGE 

LOCATION  OF  COOE 

SECURITY  CLASS  (PARTI 

SECURITY  CLASS  (CATALOG  ENTRY) 

UNES  OF  CODE  (SOURCEI 

FIXEO  OBJECT  COOE  SIZE 

REQUIREMENTS  DOCUMENTATION 

OESIGN  DOCUMENTATION 

HARDWARE  OEPENOENCIES 

OTHER  RESTRICTIONS 

ACCURACY 

TIMING  CHARACTERISTICS 

REMARKS 

Figure  2.  Catalog  Attributes 


5.  DOCUMENTATION  REQUIREMENTS 


In  order  to  ensure  that  all  necessary  Information  Is  supplied  when  a  part 
enters  the  parts  catalog  system,  a  standard  form  should  be  developed  and 
utilized.  Appendix  B  provides  an  example  of  such  a  form;  this  Is  the  form 
used  In  the  development  of  the  MDAC  Ada  parts  catalog.  Some  of  the  Items  on 
the  form  could  be  supplied  automatically  as  a  software  part  enters  the  system 
(e.g.,  L 1nes_of_Code,  Un1ts_W1 thed ,  WlthlngJJnlts) .  This  form  can  be  used 
for  both  In tra  company  and  Inter- company  cataloging,  although  the  level  of 
detail  of  Information  provided  In  certain  fields  will  vary  depending  upon  the 
scope.  Appendix  A  discusses  the  scope-dependent  differences  In  attribute 
Information. 

Parts  documentation  Is  crucial  to  the  success  of  any  software  reusability 
effort;  Information  Indicating  the  type  of  documentation  and  Its  availability 
should  be  provided  for  each  part  In  the  catalog. 

Although  reusable  software  has  been  discussed  for  a  number  of  years.  Its 
Implementation  Is  fairly  recent,  therefore,  the  user  must  be  provided  with 
documentation  and  training  material  for  use  of  the  parts  catalog,  both  from 
the  viewpoint  of  a  catalog  user  and  as  a  developer  of  software  that  will  be 
cataloged  for  future  reuse. 

6.  ORGANIZATIONAL  FACTORS 

Organ  1  zat Iona  1  factors  play  a  critical  role  In  the  success  of  any  attempt 
to  Implement  reuse  of  pre  built  software  parts.  Although  the  scope  of  the 
catalog  has  a  direct  bearing  on  the  exact  nature  of  the  organizational 
factors  that  must  be  addressed,  the  Issues  remain  essentially  the  same. 

Figure  4  summarizes  the  organizational  factors  required  to  support  a  viable 
parts  Identification  effort. 


•  MOTIVATION  FOR  REUSE 

•  CENTRAL  REPOSITORY 

•  STANDARDS 


•  PROCEDURAL  CONTROLS 

•  TRAINING 

•  USER  SUPPORT 


Figure  4.  Organizational  Factors 


a.  Motivation  for  Reuse 

As  stated  earlier,  software  development  that  makes  use  of  pre-bullt 
software  parts  requires  discipline  on  the  part  of  the  developer.  It  also 
requires  an  Initial  Investment  of  time  and  effort  to  establish  a  reusability 
program.  Until  the  benefits  of  reuse  become  apparent  to  all  Involved,  there 
must  be  motivation  for  organizations  and  Individuals  to  reuse  existing 
software  In  a  structured  way.  Although  In  the  long-run  reuse  of  existing 
software  parts  can  produce  significant  economic  gains,  some  form  of 
motivation  will  be  required  Initially.  The  form  that  this  motivation  may 
take  Is  scope -dependent  (see  figure  5). 


MOTIVATION  BY  CONTRACTOR 

MOTIVATION  BY  CUSTOMER 

-  COMPANY  STANDARD 

•  DOD  MANDATE 

•  SUGGESTED  COMPANY  PRACTICE 

•  CONTRACT  REOUIREMENT 

•  COMPETITIVE  EDGE 

•  CONTRACT  INCENTIVE 

Figure  5.  Forms  of  Motivation 


At  one  extreme,  motivation  could  be  provided  in  the  form  of  a  DOD 
mandate  similar  to  that  for  the  use  of  Ada.  Due  to  the  extremely  broad  scope 
of  such  a  mandate,  this  Is  not  considered  an  optimal  form  of  motivation  at 
this  time. 
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The  Air  Force  could  provide  motivation  In  the  form  of  contract 
Incentives  or  contract  requirements.  Incentives  could  take  the  form  of 
giving  companies  that  have  reusability  programs  In  place  greater 
consideration  In  proposal  reviews.  Motivation  could  also  take  the  form  of 
only  considering  companies  that  have  reusability  programs  In  place. 

Although  cost-plus  contracts  provide  little  Incentive  for  the 
contractor  to  economize  on  development  costs,  some  form  of  economic  Incentive 
may  be  appropriate  to  contractors  who  Initiate  or  have  In  place  a  functioning 
reusability  program.  For  example,  a  bonus  could  be  tied  to  the  amount  of 
reuse  on  a  project. 

If  Individual  contractors  are  expected  to  set  up  their  own  programs, 
the  Air  Force  should  provide  guidelines  In  order  to  ensure  comparability 
between  programs,  and  to  lay  the  foundation  for  the  Implementation  of  reuse 
of  software  on  a  more  global  scale. 

Motivation  for  software  reuse  within  a  company  can  range  from  a 
corporate  suggested  practice  to  a  strictly  enforced  company  standard.  A 
suggested  practice  may  recommend  software  parts  reuse  as  a  sound  software 
engineering  practice  and  provide  guidelines  for  developing  reusable 
software.  When  adherence  to  reusability  guidelines  Is  required,  a  system  of 
checks  and  audits  must  be  established  In  order  to  determine  compliance. 

b.  Central  Repository 

Regardless  of  the  scope  of  the  catalog  there  should  be  a  central 
repository  for  both  the  catalog  and  the  parts.  This  eliminates  redundancy, 
reduces  overhead,  and  facilitates  maintenance,  control,  and  use  of  the 
catalog  and  parts.  Ideally  users  would  be  able  to  access  the  catalog  and 
parts  database  from  remote  locations.  Ihe  need  for  a  central  repository  has 
been  supported  by  a  number  of  researchers.  Including  DeRoze  (Reference  18) 
who  performed  a  study  of  defense  software. 

c.  Standards 

Adherence  to  coding  and  documentation  standards  Is  Important  to  the 
success  of  the  reusability  concept.  The  development  of  a  set  of  usable 
standards  Is  a  non  trivial  task  whose  Importance  should  not  be 
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underestimated.  Although  the  development  of  those  standards  Is  not  within 
the  scope  of  this  study,  we  have  recommended  a  set  of  attributes  with  which 
to  characterize  software  parts. 

d.  Procedural  Controls 

Entry  of  parts  Into  the  system  must  be  carefully  controlled.  Part 
of  the  control  procedure  Involves  ensuring  that  all  required  Information  Is 
entered  Into  the  catalog  In  the  aoproprlate  format;  this  can  be  facilitated 
by  the  use  of  a  catalog  entry  form  similar  to  the  one  discussed  In  Paragraph 
5. 

Before  entering  the  system,  each  part  should  be  screened  for 
conformance  to  coding  and  documentation  standards.  A  determination  of  what 
these  standards  should  be  are  not  within  the  scope  of  this  study,  but  they 
should  be  comprehensive  and  quantitatively  enforceable. 

Quality  assurance  Is  critical  to  the  success  of  parts  reuse;  this 
was  found  to  be  a  recurring  theme  In  the  literature  reviewed  (References  1 
and  19).  Poor  quality  parts  cause  two  problems: 

Encounters  with  a  few  poor  quality  parts  can  destroy  user 
confidence  In  all  of  the  parts. 

Poor  quality  parts  negate  the  benefits  of  reusability  (l.e., 
reduced  cost  of  development,  greater  reliability  of  the  systems 
developed) . 

Verification  of  correctness  of  software  parts  Is  a  complicated 
Issue.  Ideally,  each  part  entering  the  system  should  be  Independently  tested 
and  certified  as  meeting  Its  requirements.  If  the  catalog  Is  to  be  for  all 
Air  Force  development,  Independent  certification  will  require  extensive 
resources  In  terms  of  both  personnel  and  equipment.  If  the  scope  Is 
Intra-company,  the  QA  procedures  that  are  currently  In  place  could  be  used  as 
the  basis  for  developing  a  verification  and  certificate  process  for  parts. 
At  the  very  least,  It  should  be  required  that  the  provider  of  the  part 
Identify  the  type  of  verification  performed  and  who  (or  what  organization) 
performed  that  verification. 


Configuration  control  Is  another  Important  aspect  of  procedural 
controls  required  for  a  software  parts  catalog.  Users  should  not  be  allowed 
to  make  random  additions  of  new  parts,  or  Indiscriminately  create  new 
versions  of  existing  parts.  There  must  be  adequate  justification  for  a  new 
version  of  an  existing  part  (e.g.,  correction  of  an  error,  major 
enhancement).  Instantiations  of  meta -parts  should  not.  In  general,  be 
Included  In  the  parts  catalog  because  these  are  application-specific  (l.e., 
tailored  to  a  specific  application)  software  components  rather  than  general 
or  domain  specific  parts. 

As  stated  earlier,  new  parts  must  go  through  adequate  quality 
control  procedures  before  entering  the  catalog  system.  If  possible,  users 
should  be  notified  well  In  advance  of  any  updates  to  the  cataloged  parts; 
this  provides  the  user  with  time  to  plan  for  the  new  or  updated  part.  This 
procedure  Is  followed  by  the  Numerical  Algorithms  Group  (see  paragraph  2b). 

e.  Training  Requirements 

Training  may  be  required  In  the  use  of  the  catalog  and  associated 
documentation  procedures.  Additional  training  may  be  required  to  teach 
personnel  how  to  develop  software  that  Incorporates  existing  parts. 

f.  User  Support 

Extensive  user  support  should  be  provided  In  addition  to  the 
training  discussed  In  Paragraph  6e.  for  example,  guidelines  for  selecting 
and  using  parts  should  be  developed  and  published.  Major  updates  and 
enhancements,  and  other  Information  concerning  the  catalog  should  also  be 
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1 .  INTRODUCTION 

The  objective  of  the  Software  Generation  System  (SGS)  study  was  to 
determine  the  feasibility  of  an  automated  or  semi -automated  means  of 
developing  missile  software  that  makes  use  of  existing  software  parts.  The 
approach  taken  by  the  Investigators  was  to  first  survey  current  and  past 
research  efforts  In  this  and  related  areas  (see  Paragraph  2).  This  led  to  an 
Identification  of  Issues  and  the  development  of  a  set  of  evaluation  criteria 
that  could  be  applied  to  existing  and  proposed  systems  (see  Paragraph  3). 
Next,  a  conceptual  framework  was  developed  to  facilitate  the  determination  of 
technology  requirements  for  an  Ideal  software  generation  system  (see 
Paragraph  4).  Finally,  based  on  an  evaluation  of  current  and 
state  of  the-art  technology,  recommendations  for  systems  with  current  and 
mid  term  feasibility  were  developed  (see  Paragraph  5). 

2.  REVIEW 

Over  the  years  there  has  been  a  wide  range  of  views  on  the  nature  of 
software  generation  systems.  As  technological  advances  are  made, 
researchers'  expectations  of  these  systems  also  advance  (e.g.,  FORTRAN  was 
originally  thought  of  as  an  automatic  program  generator).  The  current  desire 
for  software  generation  systems  Is  motivated  by  the  same  forces  that 
motivated  development  of  high  order  languages  (HOL's),  and  assembly  languages 
before  them  better  software  faster  and  cheaper  (References  20  and  21). 
Although  there  Is  still  no  general  consensus  on  the  exact  nature  of  such  a 
system,  there  is  a  consensus  that  their  use  will  significantly  reduce 
software  development  time  and  cost. 
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In  researching  the  feasibility  of  automating  the  software  generation 
process,  the  goals  of  that  automation  must  be  kept  In  mind.  These  goals  are 
summarized  In  Figure  6. 


Figure  6.  6oals  of  Automating  the 
Software  Generation  Process 


An  automated  software  generation  system  simplifies  the  programming 
process  by  reducing  the  need  for  detailed  programming  knowledge.  This  Is 
achieved  by  allowing  the  software  to  be  specified  at  a  much  higher  level  of 
abstraction  than  Is  possible  with  manual  programming,  and/or  requiring  the 
'programmer'  to  be  less  precise.  The  ultimate  goal  of  a  software  generation 
system  is  to  allow  programming  to  be  performed  by  domain  engineers  rather 
than  software  engineers;  this  would  mean  fewer  programmers  would  be  required 
resulting  In  a  significant  cost  savings.  Automated  software  generation  that 
Involves  reuse  of  pre-bullt  parts  would  realize  additional  cost  savings  by 
reducing  the  amount  of  software  that  would  have  to  be  developed. 

Improved  reliability  Is  another  goal  of  automation  of  the  software 
generation  process  (e.g.,  fewer  coding  errors).  The  use  of  pre-bullt 
software  parts  would  yield  benefits  In  this  area  also;  the  parts  would  have 
been  previously  tested  and  verified,  thus  less  time  and  effort  would  be 
required  for  testing  and  debugging  of  new  software  systems. 

Many  researchers  have  tried  to  develop  universal  software  generation 
systems  (l.e.,  systems  that  are  applicable  to  all  problem  domains)  with  the 
result  being  that  they  are  not  particularly  well  suited  to  any  given  domain. 
Because  of  their  generality,  software  specifications  required  by  these 
systems  often  necessitate  nearly  the  same  level  of  detail  as  that  associated 
with  ordinary  programming.  Additionally,  the  lack  of  domain  specific 
knowledge  often  results  In  significantly  less  efficient  code  than  could  be 
produced  by  a  human  coder.  A  number  of  researchers  have  noted  that  most 
success  in  the  automation  of  software  generation  has  come  from  systems  with 


modest  goals,  l.e.,  systems  attempting  to  deal  with  limited  application 
domains  and  a  limited  range  of  user  proficiency  (e.g.,  Prywes,  Reference  22). 

As  mentioned  earlier,  the  CAMP  study  Is  Interested  In  software  generation 
systems  that  make  use  of  existing  software  parts;  this  requires  a  way  to 
describe  existing  parts,  store,  manage,  and  retrieve  them,  and  Integrate  them 
Into  future  software  development  projects.  In  the  past.  It  was  almost  as 
difficult  to  determine  If  an  existing  software  part  would  meet  a  user's 
requirements  as  It  was  to  (re-)develop  the  part.  Generally,  little  or  no 
documentation  was  available.  The  documentation  that  was  available  was  poorly 
written  making  It  difficult  for  the  (potential)  user  to  determine  the 
functionality  and  appropriateness  of  a  software  part.  Additionally,  the 
quality  of  available  components  was  unreliable.  (Software  parts  cataloging 
and  Its  associated  problems  were  discussed  In  Section  II.) 

As  part  of  the  Investigation  Into  the  feasibility  of  an  automated 
software  generation  system,  existing  work  In  the  technology  areas  that  are 
relevant  to  software  generation  systems  (l.e.,  automatic  programming,  expert 
system  appl Icatlons ,  formal  specification  systems,  natural  language 
Interfaces,  and  text  generation)  was  surveyed.  The  literature  surveyed 
contained  a  great  deal  of  ambiguity  In  the  usage  of  terms  such  as  automatic 
programming,  program  generator,  and  software  generator.  Some  researchers  use 
the  terms  automatic  programming  and  program  generator  Interchangeably,  while 
others  distinguish  between  the  two.  Program  generators  are  often  considered 
more  mechanical  In  nature,  not  Involving  the  expert  system  reasoning 
capabilities  often  associated  with  automatic  programming.  In  our  view, 
automatic  programming  and  automatic  software  generation  are  equivalent, 
although  the  term  automatic  programming  appears  to  be  used  more  frequently  In 
recent  research;  we  will  use  the  phrase  software  generation. 

The  remainder  of  this  paragraph  contains  a  summary  of  our  findings.  We 
will  first  look  at  automatic  software  generation  systems  In  the  large,  and 
then  provide  a  detailed  look  at  three  fairly  recent  systems.  Next,  we  will 
look  at  the  major  architectural  components  of  such  a  system  (l.e.,  the 
specification  technique,  the  method  of  operation,  and  output  generation).  An 
alternative  to  software  generation  Is  the  use  of  expert  system  assistance  In 
the  development  process.  This  Is  of  particular  Interest  to  us,  as  one  of  the 
goals  of  the  CAMP  study  was  to  Investigate  the  feasibility  of  an  automated  or 
semi  automated  means  of  developing  missile  flight  software.  Expert  system 


assistance  has  often  been  Incorporated  Into  proposals  for  fully  automated 
systems.  Two  representative  systems  are  presented  In  Paragraph  2e.  Figure  / 
summarizes  our  presentation. 


Figure  7.  Summary  of  Review 

a.  Automatic  Software  Generation 

An  Automatic  Software  Generation  System  Is  a  software  system  that 
automatically  generates  software  when  given  a  requirements  specification  In  a 
very  high  order  language  (VHOL).  VHOL's  allow  specifications  to  be  provided 
at  a  higher  level  of  abstraction  than  HOL's,  just  as  HOL’s  provided  a  higher 
level  of  abstraction  than  assembler  languages.  The  form  of  the  VHOL  can 
range  from  very  formal  specification  languages  to  natural  language; 
specification  techniques  are  discussed  in  Paragraph  2b. 

In  addition  to  the  specification  technique,  software  generation 
systems  can  be  characterl zed  by  their  method  of  operation,  their  target 
language,  and  the  problem  domain  (Reference  23).  The  method  of  operation  Is 
the  technique  employed  to  change  the  initial  specification  into  a  software 
part.  There  are  a  number  of  operational  methods  that  a  software  generation 
system  can  Incorporate;  they  are  discussed  In  Paragraph  2c.  The  target 
language  Is  the  language  in  which  the  software  will  be  generated.  In  the 
case  of  the  CAMP  study,  the  target  language  of  Interest  is  Ada.  The  problem 
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domain  refers  to  the  application  area  for  which  software  will  be  generated 
(e.g.,  missile  flight  software).  It  can  be  seen  that  a  wide  range  of 
technology  areas  are  covered  by  software  generation  systems. 

The  scope  of  software  generation  systems  can  vary  significantly. 

Some  systems  are  designed  to  generate  single  program  units  while  others  are 
Intended  to  generate  entire  software  systems.  Still  others  are  designed  to 
generate  only  specific  parts  of  program  units  (e.g.,  data  structures). 

Host  software  generation  system  Implementations  are  In  the  research 
phase,  or  at  Ihe  stage  that  only  relatively  small  programs  can  be  developed. 
According  to  Neighbors  (Reference  17),  specification  and  requirements 
analysis  present  the  major  Impediments  to  the  development  of  complete 
software  generation  systems. 

Software  generation  systems  do  not  necessarily  Involve  reusable 

software  parts,  and  most  systems  developed  to  date  do  not.  A  few  recently 

developed  systems  Incorporate  reusability  of  some  form;  they  Include  DRACO, 

TM 

DARTS  ,  and  USE. IT;  these  systems  are  discussed  In  the  fol  owing 
paragraphs . 

( 1 )  ORACO 

DRACO  (Reference  17)  Is  an  Interactive  software  generation  system 
developed  by  Jim  Neighbors  at  the  University  of  California  at  Irvine.  The 
system  allows  solutions  to  classes  of  problems  to  be  developed.  Once  a 
solution  to  a  particular  class  of  problems  has  been  developed.  Individual 
systems  can  be  developed  by  personnel  who  are  not  necessarily  software 
engineers . 

Development  begins  with  a  determination  of  the  existence  of  an 
appropriate  modeling  domain  for  the  problem  area  (e.g.,  missile  flight 
software).  A  modeling  domain  Is  essentially  a  model  of  the  type  of  system 
the  user  wishes  to  develop.  If  a  modeling  domain  does  not  exist,  a  domain 
expert  must  perform  a  domain  analysis.  The  domain  analysis  takes  a 
high-level  look  at  the  objects  and  operations  that  are  used  (required)  In  the 
problem  domain.  Domain  analysis  differs  from  systems  analysis  In  that  domain 
analysis  examines  the  objects  and  operations  that,  are  required  by  systems  of 
a  particular  class  rather  than  looking  at  the  requirements  for  one  particular 
system. 
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If  It  Is  not  likely  that  a  number  of  similar  systems  will  be  built, 
domain  analysis  should  not  continue;  Instead  a  custom  system  should  be 
constructed.  Domain  analysis  Is  an  expensive,  time-consuming  task  that 
requires  extensive  knowledge  of  the  problem  domain.  For  this  reason,  DRACO 
Is  not  well  suited  for  the  development  of  one-of-a-kind  systems. 

Domain  analysis  results  In  the  development  of  a  domain  model  and  a 
domain  language.  The  domain  language  encapsulates  the  design  aspect  of  the 
application,  and  Is  Intended  to  allow  users  to  communicate  In  a  language  with 
which  they  are  familiar  rather  than  requiring  them  to  learn  an  ordinary  high 
order  language  for  programming.  Each  object  and  operation  In  the  domain 
language  Is  represented  by  a  software  component  (l.e.,  a  part).  Host  domain 
languages  are  quite  different  from  ordinary  programming  languages  (e.g.,  a 
domain  language  may  take  the  form  of  a  table).  It  Is  through  use  of  the 
domain  language  that  reuse  of  design  takes  place. 

The  user  specifies  the  problem  In  a  domain  language  program;  the 
domain  language  program  then  undergoes  a  series  of  refinements  that  are 
guided  by  the  user  or  by  a  predefined  strategy,  to  produce  an  executable 
program.  The  refinement  history  Is  saved  along  with  the  executable  code  that 
Is  produced. 

We  have  Identified  several  aspects  of  the  DRACO  system  which  make 
Its  widespread  usability  In  the  missile  flight  software  domain  questionable. 

The  DRACO  system  Is  still  In  the  early  stages  of  development, 
and  considerably  more  work  Is  required  to  make  It  a 
production-quality  system. 

The  specification  technique  of  the  DRACO  system  Is  designed  for 
ease  of  use,  but  the  user  still  must  learn  a  formal 
specification  language  and  technique  In  order  to  use  the  system. 
Considerable  detail  Is  required  on  the  part  of  the  user  when 
specifying  requirements. 

Efficiency  Is  another  concern  with  the  DRACO  system.  The  code 
produced  Is  claimed  to  be  very  efficient,  but  DRACO  Is  a 
universal  software  generation  system,  and,  as  we  have 
previously  pointed  out,  the  efficiency  of  the  code  produced  by 
these  types  of  systems  is  frequently  Inadequate  for  the  types 
of  applications  with  which  we  are  concerned  (l.e.,  real  time 
embedded  systems). 


(2)  DARTS 
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DARTS  (Development  Arts  for  Real  -Time  Systems)  (References  24, 

25,  and  26),  developed  by  General  Dynamics,  also  allows  solutions  to  be 
developed  for  classes  of  problems.  The  goal  of  the  research  leading  to  the 
development  of  the  DARTS  technology  was  that  once  end  users  had  a  working 
system  in  place,  they  would  be  able  to  generate  similar  systems  without 
programmer  assistance.  The  user  would  enter  the  system  specifications  In 
some  domain  language,  and  through  a  series  of  transformations,  the 
specifications  would  get  translated  to  source  code. 

One  premise  upon  which  the  technology  was  developed  Is  that 
creativity  is  only  really  required  In  the  development  of  the  first 
Implementation  of  a  particular  class  of  app 1 1  cations ;  significantly  less 
creativity  is  required  for  the  development  of  each  successive  system  of  a 
given  class.  Thus,  after  the  Initial  system  Is  developed,  It  should  be 
possible  to  generate  additional  systems  of  the  same  class  automatically  using 
the  original  system  as  a  prototype. 

Efficiency  was  an  Important  consideration  In  the  development  of  the 
DARTS  technology.  Just  as  it  Is  In  the  CAMP  study.  The  developers  of  the 
DARTS  technology  wanted  the  automat Ically  generated  systems  to  be  at  least  as 
efficient  as  custom  systems.  As  with  DRACO,  DARTS  Is  a  universal  software 
generation  system,  and  It  is  not  clear  that  the  code  It  can  produce  Is 
efficient  enough  for  the  missile  flight  software  domain. 

When  a  problem  Is  Initially  Identified  as  being  a  candidate  for 
solution  by  the  DARTS  technology,  an  analyst  must  perform  a  domain  analysis 
and  design  a  general  software  solution  to  the  problem;  a  working  system  may 
already  exist  In  the  problem  class.  Once  the  Initial  software  system  is  In 
existence,  it  must  be  generlclzed,  or  In  the  DAR1S  terminology,  made  Into  an 
archetype.  During  this  time  it  is  also  necessary  to  develop  a  domain 
language  and  translator.  AXE,  the  language  component  of  the  DARTS  system,  is 
extensible,  and  should  be  extended  to  Incorporate  the  domain  language.  The 


domain  language  Is  Intended  to  facilitate  user  Interaction  with  the  system, 
but  It  still  requires  the  learning  of  another  specification  language.  The 
requisite  knowledge  bases  for  the  application  must  also  be  developed.  The 
end  result  of  the  domain  analysis  phase  Is  that  an  environment  is  created 
that  allows  users  to  completely  specify  software  systems  without  programmer 
assistance;  code  Is  generated  automatically  once  the  specifications  are 
determined  to  be  complete. 

Existing  software  Is  generlclzed  by  embedding  AXE  statements  In  the 
source  code;  these  statements  are  used  to  direct  software  generation  by 
referencing  the  system  knowledge  bases.  Actual  software  or  code  generation 
takes  place  through  a  series  of  transformations.  Each  class  of  system  (or 
application  area)  essentially  has  Its  own  software  generator  (l.e..  Its  own 
archetype).  AXE  statements  can  also  be  embedded  In  documentation  to  allow 
the  automatic  generation  of  new  documentation  along  with  a  new  system. 

DARTS  provides  a  way  to  generate  a  family  of  modules.  The  domain 
analysis  and  language  development  are  time  consuming  and  relatively  expensive 
tasks  that  require  extensive  knowledge  of  the  domain.  Prior  to  developing  a 
general  solution  for  an  application  area,  an  assessment  must  be  made  as  to 
the  likelihood  that  many  similar  systems  will  be  needed  or  if  the  required 
system  will  probably  be  one-of-a-kind.  Because  of  the  costs  involved,  this 
technology  should  not  be  applied  unless  there  Is  a  foreseeable  need  for 
several  systems  of  the  same  type. 

DARTS  is  currently  being  marketed  by  General  Dynamics,  but  at  the 
time  of  our  study,  we  were  unable  to  obtain  conclusive  evidence  from  General 
Dynamics  concerning  its  appropriateness  to  the  missile  flight  software  domain 

(3)  USE. IT 

USE. IT  (References  27  and  28),  a  commercial  system  developed  by 
Higher  Order  Software,  Inc.  (HOS),  allows  a  user  to  specify  unit  requirements 
via  a  graphic  specification  technique.  The  specifications  take  the  form  of  a 
hierarchical  tree  structure  which  Is  referred  to  as  a  control  map.  The  leaf 
nodes  of  the  control  map  are  system  primitives  or  external  routines  developed 
by  a  programmer.  HOS  provides  the  system  with  only  very  low-level 
primitives;  It  is  left  to  the  user  (or  installation)  to  develop  higher  level 
primitives.  It  is  only  through  the  development  of  additional  primitives  and 


external  routines  that  programming  with  USE. IT  Is  raised  to  a  higher  level  of 
abstraction  than  ordinary  programming. 

The  requirements  specifications  are  analyzed,  and  If  found  to  be 
Incomplete  or  Inconsistent,  the  specification-analysis  phase  Is  reiterated. 
Once  the  specification  Is  finalized,  the  control  map  can  be  used  to 
automatically  generate  code,  or  It  can  be  used  as  a  specification  for  manual 
coding.  English-language  documentation  can  be  produced  as  a  by-product. 

Reusability  Is  manifested  through  the  reuse  of  primitives.  This  Is 
really  reuse  of  both  design  and  code  (If  the  code  for  the  primitives  Is  also 
reused  via  automated  or  manual  means). 

We  have  Identified  a  number  of  problems  associated  with  the  use  of 
this  system  for  the  development  of  Ada  missile  flight  software: 

USE. IT  does  not  generate  Ada  code  and  there  Is  no  definite  date 
In  the  future  for  the  generation  of  Ada. 

The  user  must  be  aware  of  which  primitives  exist  and  be  able  to 
choose  which  would  best  suit  his  needs  (this  may  require  a 
primitives  administrator  position  which  would  be  similar  to  a 
database  administrator). 

The  primitives  need  to  be  developed  at  a  sufficiently  high 
level  otherwise  specification  must  be  at  as  low  a  level  as 
required  for  manual  coding. 

b.  Specification  Techniques 

The  specification  technique  employed  by  a  software  generation  system 
has  a  significant  Impact  on  the  system's  usability  and  even  Its  feasibility. 
The  techniques  range  from  natural  language  (NL)  to  code-like  program  design 
languages.  When  considering  a  specification  technique,  the  Intended  user 
must  be  taken  Into  consideration;  some  techniques  require  a  substantial 
Investment  In  time  and  effort  to  achieve  effective  use.  The  specification 
techniques  covered  are  summarized  In  figure  8. 


•  NATURAL  LANGUAGE 

•  FORMAL  SPECIFICATION  LANGUAGE 

•  SEMI-FORMAL  SPECIFICATION  LANGUAGE 

•  GRAPHICAL  LANGUAGE _ 

Figure  8.  Specification  Techniques 

(1)  Natural  Language 

For  years  It  has  been  the  goal  of  researchers  to  develop 
Natural  Language  (NL)  man-machine  Interfaces.  Although  such  Interfaces  could 
be  used  for  a  wide  variety  of  man-machine  Interactions,  we  are  particularly 
Interested  In  natural  language  Interfaces  to  databases  and  software 
generation  systems.  Natural  language  Interfaces  to  software  generation 
systems  could  alleviate  many  software  development  problems  by  allowing  the 
user  to  communicate  his  requirements  directly  to  the  system  rather  than 
requiring  him  to  work  through  a  software  engineer  who  must  Interpret  and 
analyze  his  requirements. 

Due  to  the  wide  range  of  possible  inputs  and  their 
Interpretations,  the  development  of  an  NL  Interface  for  software  generation 
systems  Is  a  more  complicated  problem  than  providing  a  natural  language 
Interface  to  a  database.  Unrestricted  NL  Interfaces  have  not  yet  been 
realized,  but  some  progress  has  been  made,  particularly  within  limited 
domains  and  with  a  restricted  set  of  users;  this  finding  Is  supported  by 
several  researchers  Including  Blermann  (Reference  20)  and  Hendrix  and 
Sacerdotl  (Reference  29). 

Domain  dependent  specification  languages  are  a  special  type  of 
natural  specification.  These  are  specification  languages  that  Incorporate 
the  jargon  of  the  application  domain;  they  are  Intended  to  facilitate 
user-system  Interaction  by  providing  a  simpler  form  of  communication  than  a 
high  order  programming  language.  They  are  part  of  a  trend  towards  natural 
language  Interfaces. 


Hendrix  and  Sacerdotl  (Reference  29)  distinguish  between 
natural  language  systems  that  utilize  an  explicit  world  model  (l.e.,  a 
knowledge  base  containing  Information  on  the  world  as  the  system  needs  to  see 
It)  and  those  that  do  not.  Systems  that  do  not  require  an  explicit  world 
model  are  simpler  to  Implement  and  are  generally  used  for  applications  such 
as  database  Interfaces.  Systems  that  do  use  an  explicit  world  model  have 
been  developed  In  the  laboratory,  but  have  not  yet  progressed  Into  readily 
available  production  -qual 1 ty  systems. 

One  natural  language  system,  SAFE  (Skills  Acquisition  from 
Experts),  developed  by  Robert  Balzer,  Is  concerned  primarily  with  the 
transformation  of  a  limited  English  specification  Into  a  formal 
specification.  SAFE  is  part  of  a  larger  project  under  development  by  the 
Information  Sciences  Institute  at  USC,  to  develop  a  comprehensive  software 
generation  system. 

Greater  success  has  been  realized  In  the  Implementation  of 
natural  language  database  Interfaces  (Reference  29);  several  projects  have 
Implemented  Nl  Interfaces  of  various  types.  LADDER  (Language  Access  to 
Distributed  Data  with  Error  Recovery),  developed  at  SRI  (Reference  23),  Is  an 
NL  Interface  to  a  naval  database;  It  makes  use  of  the  LIFER  NL  system 
(Reference  301.  LIFER  is  a  utility  system  that  facilitates  the  development 
of  natural  language  Interfaces.  LUNAR,  a  system  developed  at  Bolt,  Barenek, 
and  Newman  (Reference  30)  to  aid  In  geologic  analysis  of  material  brought 
back  on  the  Apollo-11  space  mission,  also  makes  use  of  a  natural  language 
database  Interface.  Natural  language  Interfaces  have  been  successful  In 
these  cases  for  two  reasons:  the  goals  have  been  relatively  modest,  and  the 
application  domain  has  been  limited. 

A  natural  language  Interface  can  also  be  used  to  assist  a  user 
In  the  development  of  database  queries.  RENDEZVOUS  (Codd,  1978)  (Reference 
23)  Is  one  such  system.  It  carries  on  a  clarifying  dialog  via  a  series  of 
menus  that  provide  the  user  with  options  fo  further  Input  and  output.  At 
the  conclusion  of  the  dialog,  the  system  produces  a  natural  language  summary 
of  Its  interpretation  of  the  user’s  request. 
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(2) 


Formal  Specification  Languages 


Formal  Specification  Language  systems  make  use  of  very  high 
order  languages  to  specify  requirements.  The  complexity  of  these  systems 
varies  greatly;  they  can  be  used  to  specify  everything  from  entire  systems  to 
Individual  program  units.  The  nature  of  the  specification  language  has  a 
significant  Impact  on  the  system  In  which  It  Is  Incorporated. 

Specification  languages  (SL)  can  be  classified  as  procedural  or 
non  procedural.  Procedural  languages  describe  not  only  what  to  do,  but  how 
to  do  It;  most  ordinary  programming  languages  fall  Into  this  category. 

Non  procedural  languages  merely  describe  what  needs  to  be  done  (e.g., 
database  query  languages);  they  generally  require  less  skill  to  use  than 
procedural  languages,  and  are  at  a  higher  level  of  abstraction. 

Specification  languages  can  be  further  classified  as  domain  Independent  or 
domain  specific.  Some  systems  Incorporate  extensible  languages  that  allow 
the  development  of  specification  languages  tailored  to  a  particular  domain 
area  (e.g. ,  DAR1S) . 

Stoegerer  (Reference  31)  has  partitioned  specification 
languages  Into  three  classes:  requirements  specification  languages,  (system) 
design  specification  languages,  and  program  design  languages  (the  CAMP 
Investigators  have  classified  program  design  languages  as  a  Semi-Formal 
Specification  Technique),  tn  reality,  the  distinction  between  the  classes 
tends  to  be  somewhat  hazy.  Stoegerer  and  others  have  suggested  Integrating  a 
cohesive  set  of  specification  languages  Into  a  software  development 
environment . 

Two  examples  of  requirements  specification  languages  are  RSL, 
the  requirements  specification  language  associated  with  the  Software 
Requirements  Engineering  Methodology  (SRIH)  developed  by  TRW  for  the  Army 
Ballistic  Missile  Advanced  Technology  Center,  and  PSL  (Problem  Statement 
Language),  the  requirements  specification  language  portion  of  the  tool 
PSL/PSA  (Problem  Statement  Analyzer).  Both  RSL  and  PSA  are  tallorable, 
structured  English  specification  languages  (l.e.,  the  languages  can  be 
extended  or  tailored  to  fit  the  needs  of  a  particular  project)  but  both 
suffer  from  a  relative  lack  of  use.  This  emphasizes  the  fact  that  formal 
specification  languages  are  typically  difficult  to  work  with.  Training  In 
either  technique  can  take  1-2  months  (Reference  32),  and  training  must  be 


provided  not  only  for  those  who  will  be  writing  requirements  specifications, 
but  also  for  those  who  must  read  them. 

Both  the  DRACO  and  DARTS  systems  provide  extensible 
specification  languages  that  can  be  tailored  to  form  domain  specific 
specification  languages.  Many  other  systems  utilize  formal  specification 
languages  for  user  Inpjt;  two  of  them  are  described  briefly  here. 

MODEL  (Module  Description  language),  developed  by  Noah  Prywes 
of  the  University  of  Pennsylvania  (References  22  and  33),  Is  part  of  an 
experimental  software  generation  system.  HOOEL  Is  non-procedural  and  similar 
In  structure  to  PL/1,  lhe  user  must  supply  a  fairly  detailed  specification 
of  the  Input  and  output  data.  Assertions,  or  equations,  which  describe 
relationships  between  data  objects,  are  also  supplied  by  the  user.  The  MODEL 
program  undergoes  analysis  for  Inconsistencies,  ambiguities,  and 
Incompleteness.  After  checking  and  correction,  either  PL/1  or  COBOL  can  be 
generated.  Although  the  use  of  a  non  procedural  language  does  ease  the 
programming  burden,  the  user  is  still  required  to  learn  a  l'L/1  type  language, 
and  provide  detailed  specification  of  Inputs  and  outputs. 

Protran,  the  user  Interface  to  the  1MSL  library.  Is  an 
extension  of  FORTRAN,  and  is  not  a  part  of  a  software  generation  system. 
Programs  written  In  Protran  are  much  smaller  than  equivalent  programs  written 
In  FORTRAN,  but  the  specifications  are  not  any  less  complete  than  those 
required  for  a  FORTRAN  program. 

(3)  Semi-Formal  Specification  Languages 

Program  design  languages  (POL's)  and  specification  by  example 
are  two  forms  of  semi-formal  specification  techniques.  Program  design 
languages  can  take  many  forms;  the  ones  of  particular  Interest  to  us  are 
those  that  are  Ada  based.  McDonnell  Douglas  Astronautics  Co.  has  developed 
one  such  language,  referred  to  as  ADL  (Ada  Design  Language)  (Reference  34). 

It  consists  of  a  subset  of  Ada  and  is  intended  to  be  used  for  the  design  of 
software  systems.  Numerous  other  versions  of  Ada  based  PDL's  have  been 
developed.  There  is  currently  an  effort  under  way  by  the  IEEE  (Reference  35) 
to  establish  guidelines  for  their  development. 


One  form  of  specification  by  example  consists  of  the  user 
providing  the  system  with  Input  output  pairs;  the  system  then  generates  the 
code  that  would  result  In  the  given  output  when  supplied  with  the  specified 
Input.  A  use*-  must  carefully  construct  examples  that  completely  specify  the 
requirements.  The  development  of  a  comprehensive  example  for  more  than  a 
trivial  problem  Is  not  a  simple  task,  but  for  simple  problems.  It  has  been 
found  that  users  can  converge  on  the  correct  solution  fairly  quickly  simply 
by  providing  successive  examples;  this  has  been  noted  by  several  researchers 
(References  23  and  3b). 

Specification  by  example  has  been  Incorporated  Into  PSI,  a 
software  generation  system  developed  by  Cordell  Green  at  the  University  of 
Southern  California. 

(4)  Graphical  Specification  Languages 

Studies  have  Indicated  that  both  clarity  and  speed  of 
Infonnatlon  transfer  are  greater  with  graphic- based  languages  than  with  other 
types  of  languages  (e.g.,  formal  specification  languages,  natural  languages 
(Reference  31)).  The  use  of  graphical  languages  for  both  input  of 
specifications  and  other  man  machine  Interactions  (e.g.,  requests  for  further 
Information  from  the  user,  summaries  of  specifications)  has  been  proposed. 
Graphical  representations  allow  information  to  be  presented  concisely. 

A  Graphical  Specification  Language  requires  both  an  appropriate 
set  of  symbols  and  a  method  for  piocessing  it.  The  development  of  automated 
graphical  specification  techniques  is  still  In  the  early  stages. 

MIT  had  a  project  underway  to  develop  such  a  technique 
(Reference  37).  A  preliminary  step  in  the  development  process  was  the 
development  of  an  appropriate  set  of  symbols  to  represent  various  programming 
constructs  and  concepts.  HOS's  USE. IT  system  makes  use  of  a  graphical 
specification  technique,  although  it  is  not  at  a  very  high  level. 

Both  Booch  (Reference  38)  and  Buhr  (Reference  39)  have  proposed 
manual  graphical  representation  schemas  for  Ada  software  parts. 


c.  Methods  of  Operation 


A  software  generation  system  takes  some  form  of  requirements 
specification  as  Input,  and  generates  some  form  of  software  part  as  output. 
The  technique  used  to  change  a  requirements  specification  Into  code  Is 
referred  to  as  the  method  of  operation.  There  are,  of  course,  many  ways  to 
do  this,  but,  there  do  not  appear  to  be  any  clean  cut  lines  that  clearly 
delineate  the  methods  and  thus  facilitate  classification;  this  Is  often  the 
case  with  technologies  that  are  In  the  early  stages  of  development.  This  Is 
not  to  Imply  that  classification  schemes  have  not  been  proposed.  Some 
categories  that  have  been  suggested  are  deductive  techniques,  transformation 
techniques,  expert  system  techniques,  and  custom  tailoring. 

Custom  tailoring  Is  often  thought  of  as  using  parameterized  software 
to  generate  unique  configurations  from  a  standard  software  system.  This 
process  has  been  used  In  telecommunications  systems,  and  Is  also  the  method 
used  to  transform  generic  Ada  parts  Into  concrete  usable  Instances;  It  Is  a 
way  to  generate  families  of  concrete  software  systems  (or  programs)  from  an 
abstract  system  (or  program). 

An  expert  system  can  be  used  In  conjunction  with  any  method  of  operation, 
thus,  a  strict  classification  as  expert  system  technique  is  not  really 
meaningful . 

Deductive  or  theorem  proving  techniques  Incorporate  transformations 
that  are  usually  In  the  form  of  predicate  calculus  statements.  These 
techniques  start  with  a  theorem  to  be  proven,  and  attempt  to  find  a  series  of 
transformations  which  lead  to  that  conclusion.  A  program  Is  produced  as  a 
by-product  of  the  proof. 

The  problem  that  we  see  with  an  attempt  to  classify  the  methods  of 
operation  at  this  stage  of  development  Is  that  almost  all  methods  of 
operation  can  be  forced  Into  the  category  of  transformation  systems  (l.e., 
they  all  transform  a  specification  Into  a  software  part).  The 
transformations  can  take  a  number  of  forms:  they  can  be  In  the  form  of 
predicate  calculus  statements,  they  can  be  In  the  form  of  rules,  or  they  can 
be  simple  substitutions. 

A  mechanism  for  selection  and  application  of  the  transformations  Is 
required.  The  amount  of  user  assistance  required  to  guide  the  application  of 
the  transformations  varies  considerably  between  systems.  Some  systems 
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require  no  user  Input  other  than  the  provision  of  the  Initial  specification, 
while  others  require  a  significant  amount  of  human  guidance  (e.g.,  Kestrel's 
proposed  Knowledge  Based  Software  Assistant).  An  expert  system  may  be  used 
to  aid  In  selection  of  the  transformations,  or  the  transformations  may  be 
applied  In  an  arbitrary  manner  or  with  the  aid  of  heuristics.  The  steps  In 
the  transformation  process  are  often  saved  so  that  the  transformation  can  be 
replayed  later  If  the  need  arises  to  re  Implement  the  software. 

The  range  of  problems  that  can  be  solved  by  any  given  method  of 
operation  varies  considerably  depending  upon  the  particular  Implementation. 

As  with  specification  languages,  the  trend  In  methods  of  operation  has  been 
towards  greater  domain  specificity  (Reference  40). 

Several  software  generation  systems  (DRACO,  DARTS,  USE. IT)  have 
previously  been  discussed,  but  we  will  briefly  summarize  how  they  produce 
programs.  In  the  DRACO  system,  a  program  specified  In  a  domain  language 
undergoes  a  series  of  refinements  (or  transformations)  that  follow  a 
pre-deflned  strategy  or  are  guided  by  the  user.  In  the  DARTS  system,  the 
archetype  system  has  AXE  language  statements  embedded  In  them  that  reference 
various  knowledge  bases.  The  user's  program  supplies  application  specific 
Information  that  Is  used  In  conjunction  with  the  Information  from  the 
knowledge  bases  to  guide  the  transformation  of  a  system  from  a  model  solution 
Into  a  specific  Instantiation.  In  HOS's  USE. IT  system,  code  modules  are 
substituted  for  primitives  In  the  control  maps;  module  Interconnections  on 
the  control  map  require  the  generation  of  code. 

PSI,  a  software  generation  system  developed  by  Cordell  Green  at 
Stanford  University  In  the  1970's,  uses  a  number  of  cooperating  experts 
(e.g.,  a  domain  expert,  coding  expert,  efficiency  expert)  to  transform  the 
specification  (which  may  be  in  the  form  of  a  series  of  examples)  Into  code. 

The  DEDALUS  system  developed  by  Manna  and  Waldlnger  at  SRI 
(References  23  and  36),  has  been  referred  to  as  a  deductive  system.  It  uses 
a  modified  form  of  predicate  calculus  (l.e.,  more  English  language  text  Is 
allowed)  for  the  specification,  and  generates  programs  In  a  language  similar 
to  LISP.  The  transformation  rules  contain  knowledge  about  both  general 
programming  principles  and  the  specific  Implementation  language.  Successive 
application  of  the  rules  leads  to  the  transformation  of  the  original 
specification  Into  the  final  program. 


d. 


Text  Generation 


i 

In  addition  to  producing  code.  It  Is  desirable  for  a  software 
generation  system  to  also  produce  documentation.  Text  generation  poses 
basically  the  opposite  problem  of  natural  language  specification.  Text 
generation  requires  the  transformation  of  an  Internal  representation  of 
Information  (l.e.,  program  specifications)  Into  English  text.  A  few  systems 
Incorporate  some  rudimentary  form  of  text  generation  (e.g.,  HOS's  USE. IT 
generates  documentation  that  the  developer  claims  meets  military  standards, 
but  It  appears  to  be  at  a  fairly  low  level).  The  DARTS  system  Is  able  to 
generate  documentation  from  generlclzed  documentation  provided  with  the 
archetyped  system.  As  was  mentioned  earlier,  the  Rendezvous  system  generates 
natural  language  summaries  of  user  specifications.  Automated  text  generation 
Is  not  highly  developed. 

e.  Expert  System  Assistance 

An  Expert  System  Is  a  software  system  designed  to  exhibit  human  like 
reasoning  behavior  (i.e.,  such  systems  are  able  to  form  Inferences  based  on 
factual  knowledge,  data,  and  rules  of  thumb).  Expert  systems  have  been 
proposed  that  would  assist  In  the  programming  task  rather  than  perform  It 
automatlca I ly . 

One  such  system  Is  the  Programmer's  Apprentice  (References  23  and 
41),  proposed  In  1976  by  researchers  at  HIT.  The  system  Is  Intended  to 
provide  assistance  In  the  areas  of  documentation,  verification,  debugging, 
and  modification  management.  The  system  Incorporates  general  programming 
knowledge;  this  knowledge  Is  stored  In  the  form  of  plans.  The  programmer  can 
either  provide  plans  for  the  solution  of  a  problem  or  provide  code.  The 
Apprentice  uses  the  plans  to  form  an  understanding  of  the  problem;  It  tries 
to  determine  If  the  code  Implementation  corresponds  to  a  valid  plan,  and  If 
there  Is  no  correspondence,  the  programmer  Is  notified.  The  Programmer's 
Apprentice  can  also  provide  assistance  In  determining  the  ramifications  of 
modifications.  A  combination  of  plans  and  user  supplied  Information  are  used 
to  generate  documentation.  Research  and  development  work  on  prototype 
systems  has  proceeded  over  the  years. 


Another  knowledge-based  programming  assistant  that  has  been  proposed 
Is  the  Knowledge-Based  Software  Assistant  (KBSA) .  In  a  study  performed  by 
the  Kestrel  Institute  for  Rome  Air  Development  Center  (Reference  42), 
researchers  proposed  the  development  of  a  system  that  would  provide 
assistance  In  all  areas  of  a  software  development  project,  from  requirements 
analysis  to  project  management.  It  Is  proposed  that  the  system  be  developed 
Incrementally  over  the  next  10  to  15  years,  with  work  proceeding  on  a  number 
of  areas  concurrently.  Formalization  of  development  practices  Is  a  key 
factor  In  automating  the  program  development  process. 

The  proposed  system  would  Interact  with  different  types  of  users  at 
the  appropriate  level  (e.g..  project  managers  would  not  be  burdened  with 
programming  details,  but  a  programmer  would  be  able  to  get  the  information  he 
needs  from  the  system).  An  Interesting  aspect  of  this  study  is  that  the 
researchers  chose  not  to  Include  as  goals  of  the  KBSA  two  Important  goals  of 
other  proposed  systems:  automatic  program  generation  and  natural  language 
Interfaces.  Natural  language  Interfaces  were  omitted  because  it  was  felt 
that  such  Interfaces  would  require  the  same  underlying  formalisms  proposed 
for  development  as  part  of  the  KBSA,  but  that  the  amount  of  research  required 
to  effectively  Implement  a  NL  Interface  Is  so  vast  that  to  do  so  would 
detract  from  the  development  of  the  remainder  of  the  KBSA.  Automatic 
programming  was  not  Included  as  a  goal  because  It  was  felt  that  the  user 
could  be  allowed  to  Interact  with  the  system  at  a  higher  level  of  abstraction 
If  he  was  also  required  to  assist  In  the  code  generation  process  (l.e.,  there 
Is  a  technology  gap  between  what  Is  fully  automatable  and  what  Is 
semi -automatable) .  For  example,  the  user  could  be  provided  with  the 
capability  to  partially  specify  software  requirements  and  have  the  system 
assist  with  their  completion. 
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3.  ASSESSMENT 


When  considering  a  particular  software  generation  system,  It  should  be 
examined  carefully  In  light  of  relevant  Issues  and  evaluation  criteria.  Two 
levels  of  Issues  and  evaluation  criteria  were  Identified  during  the  CAMP 
feasibility  study.  The  top  level  relates  to  the  system  as  a  whole  (l.e., 
reusability  Issues,  Issues  related  to  Ada  and  the  problem  domain,  technology 
Issues,  system  maintenance  and  Initialization  Issues,  and  Issues  relating  to 
physical  attributes  of  the  system),  while  the  second  level  looks  at  specific 
facilities  and  parts  of  the  system  (l.e.,  the  specification  technique  and  the 
specification  Itself,  user  support,  and  system  outputs).  Figure  9  summarizes 
these  Issues  and  evaluation  criteria;  each  category  Is  discussed  In  detail  In 
the  following  paragraphs. 

a.  Reusability  Issues 

The  CAMP  study  Is  concerned  specifically  with  the  reuse  of  existing 
software,  therefore,  any  system  examined  must  be  evaluated  In  light  of  Its 
ability  to  Incorporate  reusable  software  parts.  Few  existing  software 
generation  systems  have  such  facilities.  Figures  10  and  11  depict  two  views 
of  an  SGS — one  system  does  not  Involve  reuse  of  existing  software  and  the 
other  does. 

The  level  at  which  reuse  will  take  place  Is  Important  to  the 
structure  of  a  software  generation  system.  Reuse  can  be  at  the  analysis, 
design,  or  code  level.  HOS's  USE. IT  system  Implements  reuse  at  the  code 
level  through  the  reuse  of  primitives  (l.e.,  pre-bullt  software  parts),  but 
falls  to  provide  an  automated  parts  management  system  for  these  primitives. 
The  DARTS  system  essentially  reuses  previously  developed  software  systems 
(l.e.,  the  archetype  Is  used  to  generate  new  software  systems).  In  the  DRACO 
system,  the  emphasis  Is  on  the  reuse  of  design  and  analysis  (through  the 
reuse  of  domain  analysis  and  the  domain  language).  Each  component  and 
operation  In  the  domain  language  Is  a  software  component,  and  thus,  reuse  at 
the  code  level  also  takes  place. 


REUSABILITY 


•  IS  THE  REUSE  OF  PRE-BUILT  PARTS  SUPPORTED? 

•  AT  WHAT  LEVEL  IS  REUSE  SUPPORTED  le  g..  REQUIREMENTS,  DESIGN, 
CODE)  AND  MAINTENANCE  PERFORMED? 

•  IS  REUSE  OF  PRE-BUILT  PARTS  ENFORCED? 

ADA  AND  THE  PROBLEM  DOMAIN 

•  IS  ADA  SUPPORTED?  (i.*.,  CAN  ADA  PARTS  BE  GENERATED?) 

•  IS  THE  PROBLEM  DOMAIN  U.g.,  MISSILE  FLIGHT  SOFTWARE) 

ADDRESSED? 

•  IS  THE  CODE  PRODUCED  EFFICIENT  ENOUGH  FOR  THE  PROBLEM  DOMAIN? 

TECHNOLOGY 

•  IS  THE  TECHNOLOGY  OF  SUFFICIENT  MATURITY  FOR  INCORPORATION  INTO 
AN  AUTOMATED  SOFTWARE  GENERATION  SYSTEM? 

•  WHAT  DEGREE  OF  AUTOMATION  IS  PROVIDED? 


SYSTEM  INITIALIZATION  MAINTENANCE 

•  WHAT  IS  REQUIRED  WHEN  THE  SYSTEM  'COMES  IN  THE  DOOR'?  (i.«.,  IS 
DOMAIN  ANALYSIS  REQUIRED?  MUST  A  DOMAIN-SPECIFIC  LANGUAGE  BE 
DEVELOPED?  DOES  EXISTING  CODE  NEED  TO  BE  RESTRUCTURED?  DO 
SOFTWARE  PARTS  NEED  TO  BE  PRE-BUILT  FOR  LATER  USE?) 

•  IS  THE  SYSTEM  EASY  TO  MAINTAIN? 

•  CAN  THE  SYSTEM  EVOLVE  AS  TECHNOLOGICAL  ADVANCES  ARE  MADE? 


PHYSICAL  ATTRIBUTES  OF  THE  SYSTEM 

•  IS  THE  SYSTEM  A  REASONABLE  SIZE?  (i.a  ,  WHAT  ARE  ITS  BASIC 
STORAGE  REQUIREMENTS?) 

•  IS  THE  SYSTEM  EFFICIENT  IN  TERMS  OF  BOTH  STORAGE  AND  RESPONSE 
TIME? 


Figure  9.  Issues/Crlterla  of  a  SGS 


SPECIFICATION  TECHNIQUE  AND  THE  SPECIFICATION 


•  WHAT  TYPE  OF  SPECIFICATION  TECHNIQUE  IS  AVAILABLE?  (e  g  , 

FORMAL  SPECIFICATION  LANGUAGE?  NATURAL  LANGUAGE?  PROCEDURAL 
OR  NON  PROCEDURAL?! 

•  IS  THE  SPECIFICATION  TECHNIOUE  APPROPRIATE  TO  THE  USER?  ARE 
MULTIPLE  SPECIFICATION  TECHNIQUES  PROVIDED  SO  THAT  THE  MOST 
APPROPRIATE  ONE  CAN  BE  USED? 

•  WHAT  LEVEL  OF  EXPERTISE/TRAINING  IS  REOUIRED  TO  EFFECTIVELY 
INTERFACE  WITH  THE  SYSTEM? 

•  IS  THE  INTERFACE  TECHNIOUE  APPROPRIATE  TO  THE  PROBLEM  DOMAIN? 

•  CAN  THE  SPECIFICATION  BE  AUTOMATICALLY  TRANSFORMED  TO  A  FORM 
THAT  IS  COMPREHENSIBLE  TO  ALL  PARTIES  WHO  NEED  TO  KNOW' 

•  CAN  THE  SPECIFICATION  BE  PUT  IN  A  FORM  THAT  IS  ANALYZABLE 
(e.g.,  FOR  COMPLETENESS,  CONSISTENCY,  CLARITY)? 

•  IS  THE  SPECIFICATION  MAINTAINABLE  (IF  THE  SPECIFICATION  IS  TO 
FUNCTION  AS  A  FORM  OF  DOCUMENTATION  AND  CONTROL,  IT  MUST  BE 
MAINTAINED  IN  A  CURRENT  STATE  THROUGHOUT  THE  SOFTWARE  LIFE 
CYCLE)? 


USER  SUPPORT 

•  IS  THE  USER  ASSISTED  WITH  SPECIFICATIONS  (i.e..  IS  PARTIAL 
SPECIFICATION  SUPPORTED?)? 

•  DOES  THE  SYSTEM  SUPPORT  AN  INCREMENTAL  OR  ITERATIVE  APPROACH  TO 
DEVELOPMENT? 

•  ARE  THE  SPECIFICATIONS  CHECKED  FOR  COMPLETENESS,  CONSISTENCY. 
CLARITY? 

•  CAN  THE  USER  INTERFACE  DIRECTLY  WITH  THE  VARIOUS  COMPONENTS 
OF  THE  SYSTEM  (e  g  .  CAN  HE  DIRECTLY  QUERY  THE  PARTS  CATALOG?!? 


SYSTEM  OUTPUTS 

•  IS  OPTIMIZED  CODE  PRODUCED? 

•  IS  THE  CODE  VERIFIABLY  CORRECT? 

•  ARE  FACILITIES  PROVIDED  TO  VERIFY  CORRECTNESS  OF  RESULTING 
MODULES  (e  g  AUTOMATIC  GENERATION  OF  TEST  PROCEDURE, 
CORRECTNESS  PROOFS) 

•  ARE  SUPPORTING  DOCUMENTS  (e  g.,  ADL,  SYSTEM  DOCUMENTATION) 
PRODUCED? 


Figure  9.  Issues/Criteria  of  a  SGS  (Concluded) 
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Figure  10.  Software  Generation  without  Parts  Reuse 


Figure  11.  Software  Generation  with  Parts  Reuse 


The  level  at  which  reuse  takes  place  affects  the  level  at  which 
maintenance  will  be  performed  (e  g  .will  the  requirements  specification  or 
the  code  be  maintained?) .  If  requirements  specifications  are  maintained,  a 
record  must  be  kept  of  any  manual  changes  made  to  the  part  (1  e.,  deviations 
from  the  standard  part)  In  case  re  Implementation  becomes  necessary  at  a 
later  time.  If  the  code  Is  maintained,  the  requirements  must  be  changed  as 
changes  are  made  to  the  code.  There  are  a  number  of  advocates  of  maintenance 
of  requirements  {e.g.,  Jim  Neighbors,  Reference  17). 

Enforcement  of,  and  motivation  for,  reuse  Is  critical.  Motivation 
may  take  many  forms.  In  addition  to  organizational  motivation  for  reuse,  the 
software  generation  system  Itself  may  Incorporate  a  mechanism  to  prevent  an 
engineer  from  building  a  part  that  already  exists  (l.e.,  a  redundant  code 
detector) . 

b.  Ada  and  the  Problem  Domain 

The  CAMP  study  requires  Ada  as  the  Implementation  language  for  both 
the  pre-bullt  parts  and  the  generated  parts;  the  effect  of  this  on  the 
feasibility  of  an  automated  SGS  has  to  be  considered. 

One  of  the  key  Issues  In  this  area  Is  that  any  system  used  to 
develop  missile  flight  software  for  the  Air  Force  must  produce  efficient  code 
(both  In  terms  of  execution  time  and  storage  requirements).  Efficiency  Is 
crucial  In  this  area.  Although  currently  there  Is  some  degree  of  efficiency 
lost  Just  by  using  Ada,  we  think  that  this  will  change  In  the  near  future 
As  more  Ada  compilers  become  available,  compiler  developers  will  strive  to 
Improve  their  competitive  edge  by  producing  compilers  that  generate 
Increasingly  more  efficient  code.  This  was  seen  to  be  the  case  with  FORTRAN 
In  Its  early  stages  of  development.  Initially  there  were  objections  to  Its 
use  because  It  was  claimed  to  be  Inefficient  In  comparison  to  the  language 
with  which  most  programmers  were  familiar  (l.e.,  assembler),  but  over  time, 
the  efficiency  of  the  code  produced  by  FORTRAN  compilers  was  Increased  to  an 
acceptable  level.  We  expect  this  to  be  the  case  with  Ada  compilers  also. 

Mandating  Ada  as  a  common  language  to  be  used  for  all  DOD  software 
development  does  have  the  advantage  of  providing  an  Incentive  to  both  Improve 
Ada  and  develop  optimizing  compilers  that  will  eliminate  the  Inefficiencies 
currently  found  In  compiled  Ada  code.  Ada  Itself  Incorporates  certain 


features  that  lessen  the  effects  of  constructing  software  systems  from 
pre-bullt  parts  (l.e.,  pragma  I N_L I NE ) . 

The  problem  domain  ( 1 . e . ,  missile  flight  software)  has  a  bearing  on 
the  structure  and  acceptability  of  any  given  software  generation  system  that 
might  be  considered.  One  certain  effect  Is  that  any  software  generated  for 
this  application  area  must  be  highly  reliable.  Although  no  known  software 
generators  exist  for  the  domain  of  Interest  In  the  CAMP  study,  some  systems 
claim  to  be  tallorable  to  any  domain  (e.g.,  DARTS,  DRACO).  It  Is  not  clear 
that  the  efficiency  of  the  code  produced  by  these  systems  Is  efficient  enough 
for  the  problem  domain  under  consideration;  realistic  demonstrations  are 
required  to  prove  their  acceptability. 

c.  Technology  Issues 

The  maturity  of  the  technology  required  for  any  given  part  of  a 
software  generation  system  Is  of  prime  Importance  In  determining  the 
feasibility  of  the  system  as  a  whole.  The  stage  of  development  of  the 
technology  should  be  determined  (l.e..  Is  It  In  the  production  stage, 
laboratory  use,  or  research  phase?). 

The  degree  of  automation  provided  by  a  software  generation  system  Is 
an  Important  point  to  consider.  Generally,  there  are  trade-offs  between  the 
degree  of  automation  provided  and  other  technologically  advanced  features 
Incorporated  Into  the  system  (e.g.,  the  Knowledge  Based  Software  Assistant 
described  In  Paragraph  2e,  trades  off  higher  levels  of  abstraction  In  the 
specification  technique  against  a  lesser  degree  of  automation  In  the  software 
generation  process). 

d.  System  Initialization  and  Maintenance 

Initialization  (l.e.,  what  Is  required  to  make  the  system 
operational  for  the  end  user)  and  maintenance  of  a  software  generation  system 
are  not  strictly  related  to  the  feasibility  of  such  a  system,  but  they  have 
Important  Implications  for  Its  actual  use.  As  we  saw  In  the  survey,  some 
systems  require  an  extensive  amount  of  work  before  the  system  Is  operational 
for  a  particular  application  area.  For  example,  DRACO  requires  domain 
analysis  and  the  development  of  a  domain  language.  DARTS  (General  Dynamics) 
requires  that  an  archetype  system  be  developed  or  that  an  existing  system  be 
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archetyped;  the  specification  language  also  has  to  be  extended  for  each 
domain.  If  a  system  requires  this  type  of  work.  It  must  be  determined  who 
will  perform  It  (e.g.,  will  the  work  be  performed  by  the  Air  Force  with  each 
contractor  being  required  to  Install  Identical  systems,  will  there  be  a 
central  facility  which  can  be  accessed  by  all  contractors  as  needed,  or  will 
each  contractor  be  required  to  perform  the  work  on  their  own).  This  Is 
really  an  Issue  of  scope  of  the  system;  many  other  Issues  will  arise  from  any 
decision  made  In  this  area  but  an  examination  of  them  Is  not  within  the 
purview  of  the  current  study. 

Ease  of  maintenance  of  the  software  generation  system  Is  Important 
to  Its  continued  use.  Because  It  Is  clear  that  technological  advances  will 
be  made  over  time.  It  Is  desirable  to  be  able  to  extend  the  capabilities  of  a 
software  generation  system  as  It  becomes  feasible  to  do  so. 

e.  Physical  Attributes 

Physical  attributes  of  the  system  also  Impact  Its  feasibility.  Its 
size  and  efficiency  affect  both  where  It  can  be  used  and  by  whom. 

f.  Specification  Techniques  and  the  Specification 

The  form  of  the  specification  (l.e.,  natural  language,  formal 
specification  language,  semi-formal  specification  language,  graphical 
specification,  or  some  combination)  Is  Important  not  only  to  the  usability  of 
the  system,  but  also  to  Its  feasibility.  The  specification  technique  should 
be  appropriate  to  the  user  of  the  system  and  to  the  problem  domain.  A 
minimum  of  training  should  be  required  In  order  to  Interface  with  the 
software  generation  system. 

The  specification  should  be  In  a  form  (or  be  readily  convertible  to 
a  form)  that  Is  comprehensible  to  both  the  developer  and  the  customer.  It 
should  also  be  In  a  form  that  Is  analyzable  for  completeness,  consistency, 
and  clarity.  Finally,  the  specification  should  be  maintainable  throughout 
the  software  lifecycle. 

Figure  12  presents  a  summary  of  how  the  specification  techniques 
that  were  presented  earlier  stack  up  In  light  of  the  Issues  and  criteria 
discussed  here. 
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Natural  language  Interfaces  are  easy  to  use  and  have  the  advantage 
that  no  new  language  Is  required;  generally  the  specifications  can  be 
Incomplete  with  the  system  prompting  for  more  Information  as  needed  (this  Is 
the  partial  Information  Issue). 

The  major  drawback  of  natural  language  specification  Is  that  the 
technology  required  to  support  such  an  Interface  technique  Is  not  as  mature 
as  that  needed  to  support  formal  specification  languages.  Another  drawback 
of  NL  specifications  Is  that  they  are  not  as  concise  as  specifications  In 
some  other  forms  (e.g.,  formal  specification  languages)  and  may  become 
voluminous  for  large  systems. 

A  natural  language  Interface  makes  the  system  easier  to  use,  but 
does  not  negate  the  need  for  any  of  the  underlying  formalisms  required  by 
specification  systems  (l.e.,  the  natural  language  specification  will  require 
translation  Into  some  type  of  formal  specification  In  order  for  the  system  to 
be  able  to  analyze  It  and  generate  code);  this  was  the  point  made  by 
researchers  at  Kestrel  Institute  who  developed  the  plan  for  the  Knowledge 
Based  Software  Assistant  (Reference  42). 
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It  Is  probably  not  feasible  at  this  time  to  expect  that  an  entire 
set  of  missile  software  specifications  can  be  entered  via  a  natural  language 
Interface,  although  It  may  be  possible  for  some  of  the  Interaction  to  be 
carried  out  In  NL.  For  example,  after  analyzing  the  specifications  for 
completeness,  etc.,  the  system  could  Interact  with  the  user  In  some  limited 
natural  language  In  order  to  obtain  clarifying  Information.  To  date,  most 
success  with  natural  language  Interfaces  has  been  with  systems  that  have  a 
limited  domain  of  discourse  (Reference  20). 

The  use  of  formal  specification  languages  (l.e.,  VHOL's)  avoids  the 
technological  problems  associated  with  natural  language  Interfaces,  and 
generally  avoids  the  need  to  deal  with  partial  knowledge  (specifications  are 
generally  required  to  be  complete).  Although  these  are  advantages  for  the 
Implementor  of  the  software  generation  system  (the  technology  required  for 
these  types  of  systems  Is,  for  the  most  part,  more  mature  than  that  for 
natural  language  systems),  they  are  generally  viewed  as  disadvantages  for  the 
user  of  the  system. 

The  use  of  formal  specification  languages  necessitates  the  learning 
of  yet  another  language  In  order  to  specify  component  requirements  (e.g., 
even  "state-of-the-art"  systems  such  as  DARTS  and  DRACO  require  the  use  of  a 
formal  specification  language).  Because  of  the  large  number  of  people  who 
must  be  able  to  understand  the  specification,  this  may  not  be  feasible 
(Reference  43),  e.g.,  Stoegerer  (Reference  31)  states  that 

"  Specifications  wr1tten  In  formal  notations  are  largely 
Incomprehensible  to  the  vast  majority  of  persons  who  contract 
for  the  design  and  development  of  software  systems." 

This  Idea  Is  supported  by  the  general  lack  of  use  of  formal 
specification  languages  such  as  RSL  and  PSL  (Reference  32). 

Formal  specification  languages  facilitate  a  precise  statement  of 
requirements;  this  can  be  both  an  advantage  and  a  disadvantage.  On  the  one 
hand,  forcing  precise  requirements  from  the  user  helps  ensure  that  the 
problem  Is  well  thought  out  In  advance.  It  Is  also  a  step  In  the  direction 
of  developing  verlflably  correct  specifications.  The  disadvantage  of  this 
precision  Is  that  the  development  of  precise  specifications  requires  a  more 
educated  and  sophisticated  user. 


Because  of  the  level  of  detail  required  when  using  most  universal 
specification  languages  (1.e.t  a  single  specification  language  for  all 
application  areas),  the  benefits  of  programming  this  way  as  opposed  to 
programming  In  an  ordinary  HOL  may  not  be  significant  enough  to  warrant  a 
change  to  a  formal  specification  language.  Special-purpose  systems  (l.e., 
those  directed  to  a  particular  application  area)  may  be  somewhat  easier  to 
use  effectively,  but  they  still  require  an  Investment  of  time  and  effort  for 
additional  training. 

General  purpose  VHOL's  typically  result  In  less  efficient  code  than 
that  produced  by  HOL's  that  are  human-coded.  The  reason  for  this  Is  that, 
unlike  a  human  coder,  the  VHOL  processor  cannot  take  full  advantage  of 
domain-specific  knowledge  (Reference  20).  Some  systems  have  directly 
addressed  the  efficiency  Issue  (e.g.,  DARTS,  PSI)  but  we  have  not  seen 
conclusive  evidence  to  Indicate  that  they  have  been  successful  In  their 
attempts  at  producing  code  that  Is  efficient  enough  for  the  missile  flight 
software  domain.  More  recent  systems  stress  the  Importance  of 
domain-specific  specification  languages  and  domain  knowledge. 

POL's  are  semi-formal,  general  purpose  specification  languages,  and 
as  such,  suffer  from  the  same  drawbacks  as  general  purpose  formal 
specification  languages.  PDL’s  can  be  used  at  varying  levels  of  abstraction, 
and  this  should  be  viewed  as  an  advantage  to  their  use  as  an  Input  medium. 
Additionally,  POL's  based  on  Ada  have  been  developed,  and  their  use  for 
specifications  reduces  the  variety  of  languages  a  software  engineer  must  know. 

As  mentioned  previously,  graphical  languages  have  advantages  over 
other  types  of  languages  In  terms  of  both  clarity  and  speed  of  Information 
transfer.  They  permit  the  concise  representation  of  large  amounts  of 
Information.  The  software  and  hardware  technology  required  to  support 
graphical  Input  of  requirements  Is  still  In  the  early  development  stages; 
graphical  specification  languages  cannot  be  easily  processed  Into  a 
machine- comprehensible  form.  Booch  (Reference  38)  and  Buhr  (Reference  39) 
have  both  developed  manual  graphical  representation  schemes  for  depicting 
software  parts  at  a  high  level. 
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g.  User  Support 


The  quality  and  quantity  of  user  assistance  directly  Impacts  the 
usability  of  any  system,  and  thus  Is  of  concern  when  evaluating  a  software 
generation  system.  Specifically,  the  system  should  be  viewed  In  light  of  the 
amount  of  assistance  provided  when  the  user  Is  specifying  requirements. 
Ideally,  the  user  should  be  provided  with  an  Iterative  approach  to 
requirements  specifications.  System  checking  for  completeness,  consistency, 
and  clarity  of  requirements  Is  another  desirable  feature  of  a  software 
generation  system. 

h.  System  Outputs 

The  two  major  outputs  from  a  software  generation  system  are  code  and 
documentation.  Because  of  efficiency  concerns,  optimizing  procedures  within 
the  software  generation  system  may  be  desirable.  Correctness  of  missile 
flight  software  Is  critical;  therefore,  facilities  for  verifying  correctness 
are  also  desirable. 

The  system  should  be  further  evaluated  In  light  of  Its  ability  to 
generate  supporting  documentation.  Text  generation  Is,  as  yet,  an  Immature 
technology  area.  As  mentioned  earlier,  a  few  systems  generate  textual 
output,  but  for  the  most  part.  It  Is  done  at  a  rather  mechanical  level. 

4.  CONCEPTUAL  FRAMEWORK 

The  CAMP  Investigators  found  It  useful  to  develop  a  view  of  an  Ideal 
software  generation  system  to  serve  as  a  framework  for  developing  near-term 
and  mid-term  recommendations  for  automation  of  the  software  generation 
process;  we  refer  to  this  as  our  Conceptual  Framework.  There  are  several 
versions  of  a  software  generation  system  that  can  be  envisioned  as  we  proceed 
from  the  near-term  to  the  long-term,  but  In  this  paragraph  we  will 
concentrate  on  presenting  a  single  Ideal  system  without  emphasizing  Its 
technological  feasibility. 


a.  The  Ideal  System 


An  Ideal  software  parts  generation  system  should  have  the  ability  to 
manipulate  pre-bullt  Ada  parts,  as  well  as  the  ability  to  generate  new 
software  parts.  The  major  facilities  of  such  a  system  are  summarized  In 
Figure  13. 


t.  PARTS  IDENTIFICATION.  . 

2.  COMPONENT  CREATION . 

2a  COMPONENT  INSTANTIATION 
2b  COMPONENT  GENERATION. 

2c  COMPONENT  CONSTRUCTION 

3.  PARTS  COMPOSITION . 


THE  PROCESS  OF  SELECTING  A  PART.  OR  SET  OF 
PARTS.  FROM  A  SET  OF  PRE-EXISTING  PARTS  FOR 
A  SPECIFIC  APPLICATION 
THE  PROCFSS  OF  CREATING  A  SPECIFIC 
COMPONENT. 

THE  PROCESS  OF  CONSTRUCTING  AN 
INSTANTIATION  OF  A  GENERIC  SOFTWARE  PART 
THE  PROCESS  OF  CONSTRUCTING  A  SPECIFIC 
COMPONENT  FROM  A  SCHEMATIC  PART  BY  MEANS 
OF  A  PARTS  CONSTRUCTION  SCHEME. 

THE  PROCESS  OF  MANUALLY  BUILDING  A  SPECIFIC 
SOFTWARE  COMPONENT 
THE  PROCESS  OF  INTEGRATING  PARTS  INTO  A 
SOFTWARE  SYSTEM  UNDER  DEVELOPMENT. 


Figure  13.  Facilities  of  a  Software  Generation  System 


Before  discussing  the  technology  requirements  for  an  Ideal  SGS,  a 
scenario  of  the  system's  use  will  be  provided.  Figure  14  depicts  a 
high-level  view  of  the  system;  Figure  15  goes  Into  more  detail. 

The  software  generation  system  should  have  an  Intelligent  Interface; 
expert  system  assistance  should  be  provided  for  all  system  facilities  and 
processes.  Requirements  specification  should  be  an  Iterative  process 
performed  at  a  high  level  of  abstraction.  In  order  to  accommodate  users  with 
a  wide  range  of  backgrounds  and  needs  (l.e.,  the  user  should  not  have  to  be  a 
computer  scientist),  a  variety  of  Interface  techniques  should  be  provided 
(e.g.,  natural  language,  graphical  language,  formal  (machine  readable) 
specification  language). 

The  specification  should  not  have  to  be  complete;  the  system  should 
have  facilities  for  dealing  with  partial  knowledge.  Analysis  of  the 
specification  should  be  performed  and  should  Include  checking  for 
completeness,  consistency,  and  clarity.  Information  should  be  solicited  from 
the  user  as  needed. 
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Figure  14.  Overview  of  the  Ideal 

Software  Generation  System 


Once  the  specification  phase  Is  complete,  It  should  be  determined  If 
a  pre-bullt  part  exists  that  meets  the  user's  requirements  (this  requires 
facilities  for  automatic  location  of  existing  software  parts).  Parts  may  be 
simple  or  meta-parts  (see  Volume  I,  Section  II  for  a  discussion  of  software 
parts),  and  one  or  more  parts  may  be  located  that  meet  the  requirements.  If 
a  part  Is  located,  the  user  will  be  notified  In  order  to  prevent 
redevelopment,  otherwise,  a  new  part  will  be  built. 

The  user  should  be  able  to  recall  the  specification  In  any  of  a 
number  of  forms--textual ,  graphical,  formal  specification  language. 
Documentation  should  be  generated  as  needed. 


b.  Components  and  Requirements 

Based  on  an  analysis  of  the  scenario  depicted  In  Paragraph  4a,  the 
high  level  component  requirements  can  be  determined;  Figure  16  summarizes 
these  requirements.  Some  of  the  areas  have  previously  been  discussed  (e.g. 
specification  techniques;  parts  Identlf 1cat1on--see  Section  II);  the  other 
areas  are  discussed  In  the  following  paragraphs. 
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Expert  System  Assistance 


Expert  system  assistance  should  be  provided  throughout  the 
system.  This  requires  a  knowledge  base  management  system,  several  knowledge 
bases,  and  an  Inference  engine. 

A  knowledge  base  management  system  (KBMS)  Is  similar  to  a 
database  management  system  In  that  It  manages  and  coordinates  activities 
within  the  knowledge  bases.  KBMS's  vary  depending  upon  the  knowledge 
representation  scheme  used,  and  the  sophistication  of  the  system. 

Conceptually,  three  knowledge  bases  are  required:  (a)  the 
Missile  flight  software  knowledge  base  contains  knowledge  specific  to  the 
development  of  missile  flight  software,  (b)  the  General  software  knowledge 
base  contains  general  programming  and  program  development  knowledge,  and  (c) 
the  General  knowledge  base  Is  needed  to  support  the  Intelligent  Interface 
(e.g.,  support  of  a  natural  language  specification  technique). 

The  Inference  engine  Is  the  reasoning  mechanism  that  utilizes 
the  knowledge  bases  and  other  Input  to  draw  conclusions. 

Expert  system  assistance  Includes  a  mechanism  to  analyze  the 
completeness,  consistency,  and  clarity  of  the  requirements  provided  by  the 
user.  This  determines  when  Iteration  of  the  specification-analysis  phase 
terminates,  and  Implies  that  the  system  must  deal  with  Incomplete  (l.e., 
partial)  Information.  The  technology  required  to  support  this  mechanism 
depends  upon  the  level  of  detail  and  checking  that  will  be  performed  and  the 
way  In  which  the  analysis  will  be  performed. 

(2)  Interface  Support 

Natural  language  specification  necessitates  the  presence  of  a 
Dialog  Manager.  The  Dialog  Manager  Is  responsible  for  managing  (l.e., 
analyzing,  processing,  and  conducting)  the  natural  language  dialog  with  the 
user. 

The  Query  Manager  handles  queries  directed  to  the  database. 
This  function  would  generally  be  performed  by  the  database  management 
system.  Queries  must  be  translated  Into  a  machine  comprehensible  form.  The 
technology  requirements  for  this  component  are  dependent  upon  the  query 
specification  technique. 


Interface  support  for  an  automated  software  generation  system 
Includes  a  Loader/Unloader  for  formal  specifications  In  a  machine-readable 
form.  The  Loader  Is  needed  to  Input  machine-readable  specifications  directly 
Into  the  system;  this  Is  similar  to  loading  a  HOL  program.  The  Unloader 
outputs  machine-readable  specifications;  this  Is  analogous  to  unloading 
object  code  for  an  HOL  program. 

A  graphical  editor  Is  required  to  support  a  graphical 
specification  technique;  It  provides  an  easy  way  to  manipulate  the  components 
of  the  specification. 

A  code  editor  Is  another  requirement  of  the  Interface  support. 
Ideally,  a  syntax  directed  editor  should  be  part  of  the  automatic  programming 
environment.  Ada  syntax  directed  editors  are  currently  under  development  In 
the  commercial  sector. 

(3)  Parts  Identification 

The  Parts  Identification  facility  requires  a  parts  catalog 
which  was  discussed  In  detail  In  Section  II.  Expert  system  assistance  should 
be  provided  In  locating  parts.  Additionally,  an  automatic  code  locator 
should  be  provided  to  determine  the  existence  of  a  software  part;  this 
mechanism  would  prevent  the  development  of  redundant  code.  Such  a  mechanism 
requires  the  system  to  be  able  to  translate  the  user's  requirements 
specifications  Into  a  form  that  would  allow  formulation  of  a  query  to  the 
parts  catalog.  If  the  user  was  attempting  to  build  a  part  that  already 
existed,  he  should  be  notified  of  the  existence  of  the  part.  It  may  not 
always  be  possible  to  accurately  ascertain  the  existence  of  a  part. 

(4)  Component  Creation 

Component  Creation  consists  of  Component  Instantiation, 
Component  Generation,  and  Component  Construction.  Parts  Identification  plays 
a  role  In  determining  whether  a  part  exists  that  can  be  Instantiated  (l.e.,  a 
generic  part)  or  generated  (l.e.,  a  schematic  part),  or  has  to  be  constructed 
(either  automatically  or  manually).  Automated  component  construction 
requires  a  code  generator  and  other  supporting  mechanisms  at  a  lower  level. 
Expert  system  assistance  should  aid  In  the  creation  of  software  parts. 


(5) 


Parts  Composition 


Parts  Composition  Involves  the  Integration  of  software  parts. 
Ideally,  software  parts  composition  would  be  an  automated  process  based  on 
expert  system  knowledge  and  the  user's  requirements  specification.  Parts 
composition  requires  code  generation  to  combine  the  Individual  software 
parts.  The  degree  of  automation  of  this  facility  has  a  significant  Impact  on 
the  supporting  mechanisms  required.  HOS's  USE. IT  system  has  an  automated 
parts  composition  element,  but  this  does  not  appear  to  be  at  the  level  of 
sophistication  desired  for  the  Ideal  system  presented  here.  Research  Is 
continuing  In  this  area. 

5.  RECOMMENDATIONS 

The  recommendations  presented  here  take  Into  account  the  Ideal  software 
generation  system  presented  In  Paragraph  4,  and  temper  It  with  what  appears 
to  be  technologically  feasible.  Recommendations  are  presented  for  both  the 
near-term  and  mid-term.  We  define  near-term  to  be  In  the  range  of  0  to  3 
years,  and  mid-term  to  be  from  4  to  7  years.  The  recommendations  start  with 
a  very  basic  system  that  handles  parts  Identification,  management,  and 
generation,  and  proceed  to  a  progressively  more  sophisticated  and  fully 
automated  software  generation  system.  At  each  stage  of  development. 
Increasingly  more  sophisticated  technology  Is  required,  thus  the  design  must 
allow  for  evolution  over  time  as  technological  advances  are  made.  This  Is  a 
very  Important  aspect  of  our  recommendations.  Given  the  fast  pace  with  which 
technological  advances  are  made,  users  should  not  be  burdened  with  a  system 
made  obsolete  by  Its  Inability  for  progressive  development. 

a.  Near-Term  Recommendations 

The  system  with  the  greatest  potential  for  near-term  payoff  Is  a 
relatively  simple  system  consisting  of  parts  Identification  and  parts 
management  facilities,  and  a  parts  generation  facility  that  makes  use  of  the 
meta-parts  (generic  and  schematic  Ada  parts)  discussed  earlier.  The  parts 
Identification  facility  would  be  as  described  In  Section  II.  The  parts 
management  facility  would  keep  track  of  parts  usage  (l.e.,  where  and  by  whom 
parts  are  being  used) . 
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The  basic  scenario  for  using  such  a  system  Involves  the  user 
Interfacing  with  the  system  to  determine  the  existence  of  a  simple  or 
meta-part  that  will  meet  his  requirements.  The  user  could  either  specify  his 
needs  via  some  query  language,  or  browse  through  the  catalog.  Zero  or  more 
parts  may  be  found  that  fit  the  user's  described  needs.  If  a  part  Is  found, 
further  Information  about  It  may  be  obtained  by  accessing  the  complete 
catalog  entry.  If  a  user  selects  a  part  for  use,  the  Parts  Management  system 
must  keep  track  of  this. 

Simple  parts  may  be  used  as  Is  (l.e.,  merely  by  providing  the 
requisite  parameters).  If  a  generic  meta-part  Is  found,  the  user  must 
provide  Instantiating  Information  In  order  to  generate  a  usable  software 
component.  Schematic  meta-parts  provide  Information  on  how  to  build  the 
required  software  part;  the  user  would  perform  the  actual  construction. 

Based  on  this  scenario,  several  systems  can  be  envisaged  that  are 
currently  technologically  feasible.  One  version  of  such  a  system  could  be 
developed  with  limited  technological  requirements  (eg.,  a  database 
management  system,  a  query  language,  and  minimal  additional  supporting 
software);  Figure  17  depicts  a  simple  Parts  Identification  facility. 

The  system  could  also  be  Implemented  with  a  limited  natural  language 
or  domain  specific  specification  language,  and  some  rudimentary  form  of 
graphical  specification  technique.  As  we  have  stated  previously,  the 
technology  required  for  unrestricted  natural  language  dialog  Is  not  currently 
of  sufficient  maturity  for  production  quality  systems.  Limited  forms  of  NL 
Interfacing  are  feasible;  some  success  has  been  realized  with  limited  natural 
language  database  Interfaces.  As  mentioned  earlier,  the  technology  required 
to  support  a  full-blown  graphical  specification  technique  Is  still  In  the 
early  stages  of  development,  but  It  appears  feasible  to  provide  an  elementary 
graphical  technique.  These  additions,  while  currently  technologically 
feasible.  Impose  considerable  additional  technology  requirements  upon  the 
Implementor. 


55 


Figure  17.  Parts  Identification 

Expert  system  assistance  could  also  be  provided  for  the  parts 
Identification  and  creation  facilities.  Using  a  Parts  Identification  Expert 
(PIE)  and  a  limited  natural  language  (or  domain  specific  specification 
language),  the  user  would  specify  his  requirements,  and  PIE  would  transform 
the  specification  Into  an  Internal  form  that  could  be  used  to  access  the 
parts  catalog  to  determine  the  existence  of  the  requested  part(s).  A  Parts 
Construction  Expert  (PCE)  could  be  used  to  aid  In  the  Instantiation  and 
generation  of  components.  Figures  18  and  19  depict  an  expert  system  approach 
to  parts  Identification  and  creation,  respectively.  The  main  differences  In 
approaches  to  near-term  systems  Is  In  the  system  Interface  technique  and  the 
technology  required  to  support  It. 


Figure  18.  An  Example  of  Parts  Identification  with  an  Expert  System 


Figure  19.  Parts  Construction  with  an  Expert  System 


A  near-term  system  may  be  characterized  by  the  following: 


It  generates  single  software  units  (as  opposed  to  entire 
software  systems)  via  pre-deflned  meta-parts. 

The  specification  technique  Is  a  domain  specific  specification 
language. 

Some  degree  of  expert  system  assistance  Is  provided. 

Although  we  have  continually  highlighted  the  disadvantages  of  formal 
specification  languages,  they  are  iv.itlvely  easy  to  Implement  and  thus 
contribute  to  the  overall  feasibility  of  the  system.  The  technology 
requirements  for  the  near  term  are  .ummarlzed  In  Figure  20. 
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Figure  20.  Near-Term  Technology  Requirements 


b.  Mid-Term  Recommendations 

Most  of  the  technological  advances  will  affect  the  specification 
technique  and  the  component  creation  facility.  In  the  mid-term  we  may  expect 
the  software  generation  system  to  allow  the  specifications  to  be  provided  at 
a  higher  level  of  abstraction  than  was  previously  possible.  Additionally,  we 
may  now  expect  the  parts  creation  facility  to  progress  beyond  merely 


supplying  the  user  with  parts  constructors  to  actually  generating  code  for 
some  parts. 

The  basic  scenario  In  this  stage  of  development  Involves  having  the 
user,  via  some  high-level  specification  technique  and/or  natural  language 
dialog,  specify  his  requirements.  The  software  generation  system  would 
analyze  the  requirements  for  clarity,  consistency,  and  completeness.  The 
specification-analysis  phase  would  be  an  Iterative  process.  Once  the 
specifications  were  finalized,  an  automatic  code  locator  would  determine  If  a 
simple  or  meta-part  exists  that  would  satisfy  the  user's  requirements.  If  a 
simple  part  existed.  It  would  be  retrieved  for  the  user.  The  user  would  be 
provided  with  expert  system  assistance  for  the  Instantiation  and  generation 
of  meta-parts.  Automated  construction  of  some  parts  will  be  feasible. 

Figure  21  depicts  a  view  of  this  system. 

The  automated  parts  composition  system  designed  during  CAMP  Is 
currently  feasible  (and  thus  fits  the  near-term  classification).  It  can 
generate  complex  software  components  from  predefined  meta-parts  but  cannot 
generate  entire  systems.  It  will  make  use  of  a  limited  natural  language 
Interface  and  specification  method,  and  It  will  Incorporate  expert  system 
assistance.  Sections  IV  and  V  contain  more  Information  on  this  system.  The 
reader  Is  also  directed  to  References  44  and  45  for  a  description  of  the  CAMP 
parts  composition  system. 


figure  21.  Mid-Term  Software  Generation  System 
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1.  EXPERT  SYSTEM  OVERVIEW 

An  Expert  System  Is  a  software  system  which  emulates  the  manner  In  which 
human  experts  solve  problems.  A  particular  expert  system  Is  a  software 
system  which  has  been  given  a  body  of  knowledge  about  some  finite  domain 
( 1 . e . ,  application  area)  and  a  method  of  applying  this  knowledge  to  problems 
within  this  domain.  When  presented  with  data  about  a  specific  problem  within 
the  domain,  the  expert  system  Is  able  to  draw  conclusions  about  the  problem 
and  possibly  take  some  actions  based  on  the  conclusions  It  has  reached. 

Conceptually,  an  expert  system  has  a  very  simple  structure  (see  Figure 
22).  It's  knowledge  base  contains  all  the  knowledge  about  the  domain  over 
which  It  Is  Intended  to  be  an  expert.  The  Inference  engine  or  Inference 
generator  Is  the  mechanism  by  which  the  knowledge  Is  used  In  light  of  a  given 
set  of  problem  data  to  Infer  conclusions.  If  an  analogy  Is  made  between 
humans  and  expert  systems,  the  knowledge  a  human  possesses  would  correspond 
to  the  knowledge  base  of  the  expert  system,  and  the  physical,  electrical,  and 
chemical  mechanisms  of  the  brain  would  correspond  to  the  Inference  engine. 
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Figure  22.  The  Structure  of  An  Expert  System 


A  great  deal  of  research  has  been  performed  over  the  past  two  decades 
Into  the  structure  of  knowledge.  Much  of  this  work  Is  still  In  the 
conceptual  stage  but  some  of  It  has  been  Incorporated  Into  commercially 
available  products.  For  the  purposes  of  this  report,  the  knowledge 
structuring  mechanism  of  one  such  product,  the  Automated  Reasoning  Tool 
(ART),  will  be  used  to  Illustrate  a  typical  expert  system  knowledge  base  (It 
should  be  noted  that  ART  Is  not  typical  when  compared  with  older  systems). 
Section  V  contains  more  Information  on  ART.  ART's  knowledge  base  consists  of 
three  types  of  knowledge — facts,  rules,  and  schemata. 

A  fact  Is  a  statement  of  truth  within  the  domain  of  expertise.  F°r 
example,  the  statement  "1  Is  the  Identity  for  multiplication1'  Is  a  fact 
likely  to  be  found  In  an  expert  system  designed  to  manipulate  mathematical 
equations.  Likewise,  the  statement  "steel  Is  heavier  that  wood"  Is  a  fact. 


A  rule  Is  a  statement  of  Inference.  An  Inference  statement  can  be 
conceptualize  as  a  statement  which  says  "If  I  know  A,  then  I  can  Infer  B". 

For  example,  the  statement  "If  R  Is  transitive  and  aRb  and  bRc,  then  aRc" 
would  be  a  rule  typically  found  In  an  expert  system  designed  to  manipulate 
mathematical  equations.  Likewise,  the  statement  "If  X  Is  the  lightest 
available  material  and  X  Is  sufficient  strong,  then  use  X  In  the  product"  Is 
a  rule. 

A  schemata  Is  a  mechanism  used  to  structure  facts.  A  schemata  Is  very 
similar  to  a  data  structure  In  classical  programming  languages  In  that  It 
allows  the  aggregation  of  data  Into  a  single  entity.  A  structure  which 
contains  all  the  Information  about  a  software  part  In  a  software  parts 
catalog  would  be  an  example  of  a  schemata. 

In  the  remaining  portions  of  this  section,  the  utility  of  expert  systems 
will  be  discussed  In  various  software  parts  composition  areas.  At  the  end  of 
the  section,  a  system  will  be  presented  which  encompasses  all  these  areas 
Into  one  tool . 

2.  SCHEMATIC  PART  CONSTRUCTORS 

During  the  CAMP  domain  analysis.  It  was  determined  that  there  were  some 
types  of  commonality  which  could  not  be  Implemented  by  means  of  the  Ada 
generic  facility  alone.  In  other  words,  we  Identified  software  design 
paradigms  which  we  believed  could  be  automated  but  the  Ada  generic  facility 
was  not  sufficient  for  this  process.  We  called  these  types  of  parts 
schematic  parts.  A  schematic  part  Is  a  design  template  together  with  a  set 
of  construction  rules  used  to  build  application-specific  software  components 
from  the  template.  After  examining  various  methods  of  automating  these 
schematic  parts  we  decided  that  an  expert  system  would  be  the  best  vehicle 
for  building  the  schematic  part  constructors  (see  Figure  23). 

These  constructors  would  allow  the  user  to  specify  his  application's 
needs  for  a  specific  software  component  and  would  build  the  Ada  code  to 
satisfy  these  requirements.  This  process  Is  best  Illustrated  with  examples. 
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Figure  23.  Overview  of  a  Schematic  Part  Constructor 


Figure  24  depicts  the  structure  of  a  typical  missile's  lateral 
directional  autopilot  subsystem.  This  subsystem  was  Identified  as  a 
schematic  part  because  It  can  be  mechanically  constructed  given  basic  * 
requirements  fror;,  the  user  such  as  the  type  of  digital  filters  to  use,  the 
required  range  and  precision  of  the  data,  and  the  type  of  limiters  to  use. 
Given  this  Information,  It  Is  possible  for  an  expert  system  to  construct  the 
application-specific  Ada  code  for  this  subsystem.  It  should  be  noted  tha't 
the  expert  system  will  use  quite  a  few  non  schematic  CAMP  parts  In  this 
construction.  For  example,  It  will  use  CAMP  parts  to  construct  the  digital 
filters  and  limiters. 
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Another  example  of  a  schematic  part  Is  Illustrated  In  Figure  25.  The 
construction  of  a  navigation  subsystem  Is  dependent  upon  what  the  user  wants 
the  navigation  subsystem  to  compute,  what  data  Is  provided  as  raw  Input  to 
the  navigation  subsystem,  and  what  navigation  coordinate  system  (e.g.  wander 
azimuth,  north  pointing)  the  navigation  computation  are  to  work  within. 
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Figure  25.  The  Navigation  Schematic 


Given  this  data,  the  actual  computations  to  transform  the  Input  to  the 
required  output  are  relatively  standard.  Figure  25  Illustrates  a  schematic 
part  constructor  whose  knowledge  base  would  contain  the  standard  computations 
such  that  when  told  the  required  output,  available  Input,  and  coordinate 
system,  the  constructor  would  be  able  to  select  the  correct  computations  for 
performing  the  navigation  functions  required  to  produce  the  output. 

Appendix  0  In  this  volume  presents  a  much  more  detailed  example  of  a 
schematic  part  and  Its  constructor.  Appendix  0  Is  the  result  of  actually 
building  a  proof-of-concept  Implementation  of  one  of  the  schematic  part 
constructors . 


3.  GENERIC  INSTANTIATOR 


In  order  to  make  the  CAMP  parts  as  reusable  as  possible  while  still 
protecting  them  against  misuse,  many  of  the  CAMP  parts  were  designed  as 
generic  subprograms  or  packages  with  relatively  complex  generic  declaration 
sections.  Fortunately,  by  using  defaults  for  many  of  the  generic  functional 
parameters,  this  complexity  can  be  hidden  from  the  user.  But,  when  the  user 
wants  to  have  more  control  over  the  operation  of  the  part  (e.g.,  what  sine 
routine  It  should  use)  he  will  need  to  be  able  to  properly  Instantiate  these 
generics  so  that  the  defaults  are  overridden.  For  these  reasons,  we  believe 
some  type  of  general  purpose  generic  Instantlator  Is  needed  as  part  of  the 
software  parts  composition  system.  This  constructor  will  have  the  ability  to 
construct  the  Ada  code  for  correctly  Instantiating  any  generic  based  on  data 
It  obtains  from  the  user  by  means  of  a  dialog.  In  effect,  this  generic 
Instantlator  will  allow  the  part  designer  to  specify  what  questions  should  be 
asked  of  the  user  to  allow  the  proper  Instantiation  of  the  generic  part. 


4.  PARTS  IDENTIFICATION 

A  key  aspect  to  an  effective  software  parts  program  Is  to  provide  a 
mechanism  for  the  early  Identification  of  appropriate  software  parts. 

Software  parts  need  to  be  Identified  very  early  In  the  system  development 
process  (even  before  the  completion  of  the  software  requirements  activities) 
In  order  to  facilitate  trade-off  analyses,  cost  estimates,  software  sizing 
and  timing  analyses,  and  other  activities.  In  many  cases,  the  functions 
provided  by  a  software  parts  catalog  (to  be  discussed  In  the  next  subsection) 
are  not  sufficient  for  this  task.  What  Is  needed  Is  the  ability  to  relate 
product  characteristics  to  software  parts. 

The  software  parts  Identification  function  provides  the  user  with  the 
ability  to  find  appropriate  parts  for  a  new  application  based  only  on  high 
level  missile  requirements  and  design  Information.  In  effect  this  function 
maps  missile  requirements  to  software  parts.  Figure  26  depicts  some  sample 
rules  for  this  function.  In  this  sample,  by  knowing  that  an  anti-ship 
missile  Is  being  constructed  the  expert  system  can  Infer  the  need  for  a 
terminal  seeker  Interface  package  part. 
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RULE  1:  IF  the  missile's  target  type  Is  a  ship 

THEN  the  missile  will  contain  some  type  of  terminal  seeker 

RULE  2:  IF  the  missile  contains  a  hardware  component  X 

THEN  the  missile  software  system  will  need  a  software 
Interface  package  to  X 

RULE  3:  IF  the  missile  needs  a  software  Interface  package  to  X 
THEN  ask  the  parts  catalog  If  one  exists 

RULE  4:  IF  the  catalog  confirms  the  existence  of  part  X 

THEN  ask  the  user  If  part  X  Is  satisfactory  for  his 
application 

Figure  26.  Sample  Parts  Identification  Rules 

5.  PARTS  CATALOGING 

Examined  In  Isolation,  there  Is  little  evidence  that  an  expert  system 
needs  to  be  used  for  a  software  parts  catalog.  Although  expert  systems 
are  well  suited  for  this  type  of  application,  existing  mature  tools  such 
as  database  management  systems  can  Implement  a  software  parts  catalog 
quite  well.  8ut,  when  one  considers  the  close  Interaction  between  the 
schematic  part  constructors,  the  generic  Instantlator ,  the  part 
Identification  function,  and  the  parts  catalog,  there  are  benefits  to 
Implementing  the  parts  catalog  In  the  same  expert  system  as  the  remaining 
functions.  The  parts  catalog  provides  several  functions  for  managing 
parts  and  examining  all  Information  about  the  parts.  These  functions 
have  been  discussed  elsewhere  In  this  volume,  the  next  subsection  also 
presents  some  details  on  the  role  of  the  parts  catalog. 


6.  AMPEE  SYSTEM 


During  CAMP,  a  software  parts  composition  system  was  designed  based 
on  the  use  of  an  expert  system  that  would  provide  all  the  aforementioned 
capabilities  In  one  tool.  This  system  was  entitled  the  Ada  Missile  Parts 
Engineering  Expert  system  and  Is  summarized  In  Figures  27  and  28. 

The  advantages  of  use  using  an  expert  system  for  this  tool  are: 

a.  Expert  systems  are  useful  when  the  process  being  Implemented  are 
evolutionary  In  nature.  In  other  words,  when  the  knowledge 
changes  rapidly,  a  classical  program  would  have  to  be  recoded. 

An  expert  system  needs  only  Its  knowledge  base  changed. 

b.  Expert  systems  are  very  powerful  symbolic  processors.  Our 
Implementation  of  a  schematic  constructor  showed  that  with  a 
small  number  of  rules,  a  very  powerful  system  can  be  constructed. 

c.  Expert  systems  allow  the  construction  of  a  very  simple  user 
Interface.  Because  the  Interaction  between  man  and  machine  has 
been  a  primary  focus  of  artificial  Intelligence  since  Its 
Inception,  most  expert  systems  have  very  powerful  facilities  for 
building  Interfaces  which  allow  the  system  to  be  used  with 
minimum  training  and/or  expertise. 
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The  CAMP  program  was  tasked  to  evaluate  the  role  that  could  be  played  by 
an  expert  system  In  support  of  software  reusability  In  the  missile  flight 
software  domain  (see  Section  IV),  and  to  evaluate  a  commercially  available 
(l.e.,  an  off-the-shelf  product)  expert  system  tool  relative  to  this 
domain.  ART  ,  available  from  Inference  Corp.,  was  selected  for 
evaluation. 

ART  Is  a  commercially  available  expert  system  development  tool  that  falls 
Into  the  category  of  ar  expert  system  shell.  An  expert  system  shell  Is  a 
software  system  that  provides  the  Inference  engine  and  Infrastructure  for  an 
expert  system  thus  greatly  simplifying  the  development  of  an  expert  system. 
The  expert  system  developer  need  only  supply  the  domain  specific  Information 
for  his  application  (l.e.,  he  provides  the  rules,  facts,  etc.,  which  are 
specific  to  his  domain).  Although  this  Is  not  a  trivial  task.  It  does  bring 
the  development  of  expert  systems  within  the  grasp  of  many  more  people. 

It  must  be  emphasized  that  ART  Is  neither  an  expert  system  nor  a  software 
generation  system,  rather  It  Is  a  tool  that  can  be  used  In  the  development  of 
expert  systems.  The  CAMP  project  utilized  ART  as  the  basis  for  developing  a 
software  parts  engineering  expert  system,  but  ART  Is  not  limited  to  that 
domain  (l.e..  It  can  be  used  as  the  basis  for  development  of  expert  systems 
In  virtually  any  domain). 

ART  was  selected  from  among  the  available  products  for  a  number  of 
reasons;  they  are  summarized  In  Figure  29,  and  discussed  In  the  following 
paragraphs . 
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•  No  hardware  procurement  under  CAMP  contract 

•  Available  on  a  widely  used  processor 

•  Lower  cost  to  end-user  by  utilizing  VAX 

•  Sufficient  functionality 

Figure  29.  Why  ART  was  Selected  for  Evaluation 

The  CAMP  contract  called  for  the  procurement  of  no  additional  hardware, 
thus  It  was  almost  mandatory  to  find  a  product  that  was  available  on  a  VAX. 
Additionally,  It  was  desired  to  evaluate  a  product  that  was  hostable  on  a 
widely  available  processor.  Again,  this  pointed  to  a  product  that  was 
available  on  the  VAX. 

VAX  equipment  Is  in  widespread  use  throughout  the  DOD  and  defense 
contractor  communities,  thus  the  cost  of  adopting  the  expert  system  approach 
to  software  parts  engineering  that  Is  recommended  here  Is  much  lower  than  If 
specialized  hardware  (e.g.,  LISP  machines)  were  required.  Cost  can  be 
measured  In  terms  of  both  time  and  money.  The  monetary  cost  Is  much  less 
because  specialized  hardware  Is  not  required.  The  time  cost  Is  also  less 
because  personnel  are  already  familiar  with  the  VAX.  Familiarity  has  the 
additional  advantage  that,  although  there  are  many  new  Ideas  associated  with 
a  parts  engineering  approach  to  software  engineering,  at  least  the  tool  Is 
based  on  a  familiar  computer  system  and  thus  may  not  appear  as  radical. 

These  factors  can  contribute  substant 1 a  1 ly  to  the  probability  of  success  of 
this  type  of  software  reusability  effort. 

Many  of  the  expert  system  development  tools  that  are  commercially 
available  have  been  developed  for  specialized  LISP  hardware  such  as  the 
Symbolics  machine.  Although  these  specialized  machines  are  optimized  for 
LISP,  and  generally  provide  a  comprehensive  development  environment,  the 
additional  cost  of  acquiring  such  hardware  was  unacceptable  at  this  time  both 
from  the  viewpoint  of  developing  the  system,  and  from  the  viewpoint  of 
expecting  others  to  acquire  and  use  such  a  system.  ART  provides 
functionality  that  Is  at  least  on  a  par  with  many  of  the  products  that  are 
available  only  on  specialized  LISP  hardware;  this  functionality  Is  discussed 
in  Paragraph  3.  (Note:  ART  Is  also  available  on  both  the  Symbolics  and  LMI 
LISP  machines . ) 

Thus,  the  cost,  functionality,  and  availability  of  ART  made  It  a  feasible 
product  for  evaluation  In  the  CAMP  study. 
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2.  MEANS  OF  EVALUATION 

In  order  to  evaluate  ART,  It  was  used  as  the  basis  for  a  proof  of -concept 
Implementation  of  a  software  parts  engineering  expert  system  known  as  the  Ada 
Missile  Parts  Engineering  Expert  (AMPEE)  System,  and  as  the  foundation  for 
the  requirements  and  design  of  a  prototype  of  the  AMPEE  System.  The 
requirements  and  top-level  design  of  this  prototype  system  are  described  In 
References  44  and  45,  respectively.  The  AMPEE  System  Is  an  expert  system  to 
promote  software  reuse  In  the  area  of  Ada  missile  flight  software.  It 
provides  capabilities  to  catalog.  Identify,  and  locate  reusable  Ada  software 
parts.  It  also  provides  a  component  construction  facility  to  assist  the  user 
In  the  Instantiation  of  meta-parts.  The  proof -of-concept  Implementation 
Involved  primarily  the  Finite  State  Machine  Constructor  which  Is  described  In 
detail  In  Appendix  D  of  this  volume. 

lhe  application  did  not  entail  the  use  of  all  of  the  features  provided  by 
ART,  but  many  of  them  were  tried  with  smaller  sample  applications. 
Additionally,  one  member  of  the  CAMP  team  attended  two  weeks  of  training  In 
the  use  of  ART  and  was  able  to  try  and  discuss  features  that  were  not  used  In 
the  CAMP  application.  The  proof -of -concept  Implementation  made  use  of  the 
following  ART  features: 

facts 

relations 

schemata 

rules 

case  statement.  If-then  statement 
LISP  Interface 

3.  OVERVIEW  OF  ART 


In  the  following  paragraphs  a  number  of  ART  features  that  facilitate  the 
development  of  expert  systems  are  discussed.  Some  other  features  that  would 
be  useful,  although  they  are  rot  currently  available,  are  also  Identified, 
finally,  some  problems  and  design  Issues  that  arise  from  the  use  of  AR1  to 
develop  an  expert  system  are  discussed. 
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It  should  be  noted  that  during  the  evaluation  period,  only  Beta  versions 
of  ART  were  available  on  the  VAX.  Although  an  Improvement  was  noted  between 
Beta  versions,  Initially  functionality  was  somewhat  limited,  and  development 
was  hindered  by  system  bugs. 

a.  ART  Background 

An  ART  program  does  not  contain  functions  or  subprograms  as  are 
found  In  traditional  programming  languages  such  as  Ada  or  fortran.  Instead, 
actions  (which  traditionally  are  performed  by  subprograms,  etc.)  are 
performed  by  rules  which  fire  (l.e.,  execute)  when  all  of  their  conditions 
are  satisfied.  Rules  generally  take  the  following  form: 

If  <cond1t1on( s)>  then  <perform  specified  act1on(s)> 

Conditions  take  the  form  of  patterns  and  pattern  restrictions  which 
must  be  matched  by  data  within  the  current  state  of  the  expert  system's 
knowledge  base.  Oata  Is  represented  as  facts  which  take  a  specific  syntactic 
form  (see  the  ART  Reference  Manual,  Reference  46,  for  details). 

ART  automatically  runs  through  all  of  the  rules  that  have  been 
supplied  In  an  effort  to  determine  which  rules  have  their  conditions  met  (or 
satisfied)  by  facts  currently  In  the  knowledge  base.  Rules  whose  conditions 
are  met  are  said  to  be  Instantiated.  Instantiated  rules  are  placed  on  what 
Is  referred  to  as  an  agenda.  Only  rules  that  are  on  the  current  agenda  can 
be  fired  (l.e.,  executed). 

The  determination  of  which  rule  on  the  agenda  will  fire  Is  based  In 
part  on  priority.  The  expert  system  developer  can  assign  priorities  to  rules 
which  will  cause  an  ordering  of  rules  on  the  agenda  (l.e.,  rules  that  have 
been  Instantiated).  If  a  rule  has  not  been  assigned  a  priority,  either 
explicitly  or  based  on  the  type  of  rule.  It  will  automat  lea  I ly  be  assigned 
the  default  priority.  Rules  with  the  same  priority  are  ordered  on  the  agenda 
in  essentially  a  random  manner. 

If  a  rule  firing  causes  a  change  In  the  current  state  of  the 
knowledge  base,  the  agenda  will  be  recalculated.  In  general,  rules  do  cause 
changes  to  the  current  state  of  the  knowledge  base,  thus  one  can  effectively 
think  about  the  agenda  being  updated  after  every  rule  firing. 


At  any  given  point  In  the  running  of  the  expert  system,  a  particular 
fact  will  only  cause  one  firing  of  a  given  rule.  The  Implication  of  this  Is 
that  although  a  rule  may  still  be  Instantiated  by  a  particular  fact,  It  will 
not  remain  on  the  agenda  or  fire  repeatedly  In  what  would  essentially  be  an 
endless  loop. 

Retrieval  of  Information  from  an  ART  knowledge  base  differs  from 
retrieval  of  Information  from  a  traditional  database.  Within  ART,  searching 
Is  merely  an  outgrowth  of  the  pattern  matching  process,  l.e.,  specific 
searching  routines  need  not  be  developed  because  this  function  Is  performed 
automatically  by  the  pattern  matching  process  which  Is  an  Integral  part  of 
the  ART  environment.  Specific  rules  are  needed  to  direct  ART  to  attempt 
pattern  matching  In  search  of  specific  data  within  the  knowledge  base,  but 
this  differs  from  writing  a  traditional  search  routine. 

b.  Features  Provided 

ART  consists  of  both  a  programming  language,  and  a  development  and 
run-time  environment  for  expert  systems.  ART  Incorporates  many  features  that 
facilitate  the  development  of  an  expert  system;  these  are  summarized  In 
Figure  30.  Detailed  Information  can  be  found  In  the  ART  reference  material 
{References  46  -  49). 


•  Forward  and  Backward  Chaining 

•  Viewpoint  Mechanism 

•  Schema  Structure 

•  Relation  Facility 

•  LISP  Interface 

•  Development  Environment 

•  Debugging  Aids 


Figure  30.  ART  Features 


The  reasoning  mechanism  of  an  expert  system  Is  referred  to  as  the 
Inference  engine.  The  Inference  engine  typically  works  through  either 
forward  or  backward  chaining;  ART  Incorporates  both  reasoning  methods. 

Forward  chaining  starts  with  a  basic  premise  and  reasons  forward  to  a 
particular  conclusion.  A  forward  chaining  rule  could  be  represented  In  the 
form  'If  an  anti-ship  missile  Is  to  be  developed,  then  a  terminal  seeker  will 
be  needed'.  Backward  chaining  begins  with  a  conclusion  to  be  proven  (or  a 
goal)  and  then  attempts  to  find  a  series  of  logically  consistent  facts  and 
rules  that  support  that  conclusion.  For  example,  If  the  goal  Is  to  compute 
navigation  coefficients  and  not  all  of  the  Information  Is  Immed lately 
available,  subgoals  will  be  established  to  compute  the  required  Information. 
If  these  subgoals  can  be  satisfied,  then  the  original  goal  will  also  be 
satisfied.  Forward  chaining  reasoning  has  been  referred  to  as  being  data 
driven,  while  backward  chaining  reasoning  has  been  referred  to  as  being  goal 
driven  (Reference  50). 

Historically,  expert  systems  have  utilized  a  backward  chaining 
reasoning  mechanism.  The  parts  engineering  application  Involves  the 
potential  search  through  many  parts  In  an  attempt  to  determine  all  of  the 
parts  required  for  a  particular  application.  Backward  chaining  through  such 
a  search  space  will  not  be  as  efficient  as  establishing  a  set  of  forward 
chaining  rules  to  accomplish  tie  same  task,  thus  ART's  dual  reasoning 
mechanism  Is  a  desirable  feature  for  Incorporation  Into  the  AMPEE  System. 

ART  provides  a  powerful  viewpoint  mechanism  for  use  In  modeling  both 
temporal  and  hypothetical  reasoning.  The  temporal  viewpoint  mechanism  allows 
the  expert  system  to  reason  about  a  situation  over  time,  while  the 
hypothetical  reasoning  mechanism  allows  the  system  to  reason  about 
hypothetical  alternatives.  One  CAMP  related  area  In  which  hypothetical 
reasoning  could  be  utilized  Is  component  construction.  For  example,  If  the 
construction  of  a  component  requires  the  composition  of  several  software 
parts  from  the  Ada  missile  parts  catalog,  and  more  than  one  part  meets  the 
Initial  criteria  for  Inclusion  In  the  composite,  hypothetical  reasoning  could 
be  used  to  have  the  constructor  pursue  the  use  of  these  alternative  parts, 
lhrough  the  use  of  the  hypothetical  reasoning  mechanism,  all  alternative 
paths  to  the  construction  could  be  pursued  essentially  simultaneously.  If 
timing,  size,  or  accuracy  constraints  had  been  established  by  the  user,  this 
Information  could  be  utilized  to  select  the  appropriate  Instantiation  for  the 
user . 
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The  two  types  of  reasoning  can  be  combined  In  a  single  application. 
The  viewpoint  mechanism  also  provides  a  method  of  reducing  the  search  space. 
For  example.  If  It  Is  known  that  It  Is  a  contradiction  for  a  certain  set  of 
events  to  occur  In  the  same  viewpoint,  that  viewpoint  can  be  pruned  from  the 
search  space;  ART  will  never  allow  that  viewpoint  to  be  created  again.  ART 
also  provides  a  mechanism  for  merging  viewpoints  In  order  to  reduce 
redundancy. 

A  schema  structure  Is  provided  that  allows  automatic  Inheritance  of 
Information  between  related  schemata.  A  schema  Is  a  collection  of  facts 
about  a  particular  object.  The  Ada  software  parts  catalog  that  forms  a  part 
of  the  AMPEE  System  can  be  Implemented  via  the  schema  structure  provided  by 
ART.  This  Is  done  by  establishing  a  template  for  a  catalog  entry;  there  Is  a 
place  for  each  catalog  attribute  In  the  template.  Default  values  or  known 
properties  about  an  attribute  can  be  specified  In  this  template.  Each 
specific  catalog  entry  Is  an  Instantiation  of  the  template;  the  Individual 
catalog  entries  will  Inherit  the  default  values  and  specified  properties. 

ART  also  has  a  relation  structure  that  provides  a  simplified  means 
of  enforcing  certain  consistency  constraints.  For  example,  If  a  relation 
'upstream'  was  defined,  and  Its  Inverse  was  defined  to  be  'downstream',  then 
any  time  an  'upstream'  fact  occurred,  a  'downstream'  fact  would  be  added  to 
the  knowledge  base  automatically. 

ART  provides  a  means  of  Interfacing  to  LISP  routines.  This  allows 
the  expert  system  developer  to  write  special-purpose  LISP  routines  to  perform 
functions  not  provided  by  ART  and  to  access  those  routines  from  within  ART 
rules.  Examples  of  the  types  of  routines  that  might  be  developed  In  LISP 
Include  data  conversion  routines  and  special-purpose  Input-output. 

The  Symbolics  version  of  ART  provides  facilities  for  the  development 
of  graphic  end-user  Interfaces;  the  facility  Is  known  as  the  ARTIST.  The  VAX 
version  does  not  currently  have  this  feature  but  It  Is  expected  to  be 
available  In  the  near  future. 

The  ART  development  environment  has  several  features  to  facilitate 
system  development,  for  Instance,  the  Studio  Interface  provides  menus  for 
accessing  ART  facilities;  these  facilities  can  also  be  accessed  via 
commands.  Facilities  are  provided  for  watching  changes  as  they  occur  In  the 
knowledge  bases,  and  for  watching  the  firing  of  rules  as  the  application  Is 
run.  A  graphical  Interface  Is  available  on  the  Symbolics  version  that  allows 


the  user  to  watch  the  viewpoint  structure  during  the  running  of  the  expert 
system.  There  are  also  facilities  for  Inspecting  the  knowledge  bases  both 
before  and  after  execution,  and  for  viewing  the  static  viewpoint  structure. 
The  Symbolics  version  has  (and  the  VAX  version  will  have)  facilities  for  the 
display  of  multiple  windows;  this  allows  the  user  to  view  several  aspects  of 
system  operation  simultaneously. 

c.  Facilities  not  Provided 

One  facility  not  currently  provided  Is  for  the  use  of  variable  names 
to  reference  schema  slots,  although  this  Is  a  feature  that  Is  under 
consideration  for  Incorporation  In  a  future  release  of  ART.  This  feature  may 
not  be  needed  on  a  day  to-day  basis,  but  on  occasion.  It  would  allow  rules  of 
a  more  general  nature  to  be  written. 

Additionally,  AR1  does  not  provide  a  mechanism  for  permanently 
updating  the  Initial  state  of  the  knowledge  base  by  facts  generated  during  a 
run.  Currently  the  knowledge  base  Is  reset  to  Its  Initial  state  each  time 
the  expert  system  Is  loaded  or  reset.  This  can  cause  difficulties  In  certain 
applications,  but  It  Is  possible  to  work  around  this  constraint  by  providing 
knowledge  base  updating  routines  In  LISP  and  accessing  those  routines  from 
the  ART  application. 

AR1  does  not  currently  support  the  use  of  rule  sets.  Although  more 
than  one  ART  application  file  can  be  loaded.  If  they  are  not  all  loaded  at 
the  time  the  expert  system  Is  Initiated,  the  'reset'  that  Is  required  to  make 
an  ART  application  file  accessible,  will  cause  all  of  the  ART  files  that  have 
been  loaded  to  be  reset,  thus  restoring  the  knowledge  bases  to  their  Initial 
state. 

d.  Problems  Encountered  with  the  VAX  Version 

Ihe  VAX  version  of  ART  Is  lacking  many  of  the  'nice'  run-time 
debugging  features  that  are  available  on  the  Symbolics  version  of  the 
product.  As  mentioned  earlier,  there  are  currently  no  end  user  graphic 
Interface  capabilities,  although  work  Is  currently  In  progress  at  Inference 
to  make  this  feature  available  on  the  VAX. 


Execution  speed  has  also  been  somewhat  of  a  problem  with  the  VAX 
version  of  the  product.  Achievement  of  any  type  of  reasonable  response  time 
on  a  VAX  11/780,  required  operation  as  a  single  user.  Even  then  development 
and  debugging  proceeded  at  an  agonizingly  slow  pace.  AR1  was  rehosted  on  a 
VAX  8600  with  a  significant  Improvement  In  response  time  even  with  many  (up 
to  15)  users  on  the  system  running  all  types  of  applications.  A  three  and  a 
half  fold  decrease  In  CPU  time  was  noted  for  the  loading  of  some  ART  files. 
The  really  dramatic  Improvement  came  In  actual  elapsed  time.  ART  Is 
scheduled  to  be  targeted  for  the  Micro- VAX  II;  no  figures  are  yet  available 
concerning  expected  response  time  on  this  machine. 

Improvements  In  speed  will  come  In  two  areas:  from  the  optimization 
of  LISP  by  DEC,  and  from  the  optimization  of  ART  by  Inference. 

e.  Design  Issues 

The  Incorporation  of  ART  Into  an  expert  system  has  a  direct  Impact 
on  the  design  of  that  system.  For  example,  the  AHPEE  System  will  require  a 
non-trlvlal  amount  of  time  to  load  and  reset  on  the  VAX,  therefore  It  would 
be  desirable  to  load  In  smaller  portions  of  the  system  as  they  are  needed. 

The  problem  with  this  Is  that  In  order  for  an  AR1  application  program  to  be 

run.  It  must  first  go  through  the  load  and  reset  steps.  Load  causes  the  ART 

source  code  to  be  compiled  and  certain  data  structures  to  be  built.  Reset 
causes  any  Initial  facts  and  schemata  to  be  asserted  Into  the  knowledge 
base.  It  also  calculates  the  Initial  agenda.  If,  during  the  execution  of 
some  portion  of  the  AHPEE  System,  It  became  necessary  to  load  In  another 
portion  of  the  system,  a  reset  would  cause  all  of  the  Art-based  expert  system 
that  had  previously  been  loaded,  to  be  reset.  The  Implication  of  this  Is 
that  all  of  the  previously  fired  rules  would  become  eligible  for  firing  again 
as  the  old  facts  were  re-asserted  Into  the  knowledge  base.  Additionally,  the 

reset  wipes  out  any  Interim  facts  that  may  have  been  added  to  the  knowledge 

base  by  means  of  actions  on  the  RHS  of  rules. 

One  possible  solution  to  this  problem  Is  to  precede  the  load  and 
reset  sequence  of  commands  with  a  clear  command.  Then  previously  fired  rules 
would  not  fire  again,  but,  the  clear  would  eliminate  any  Intermediate  facts 
from  the  knowledge  base.  Additionally,  the  rules  that  had  previously  been 
loaded  would  no  longer  by  available,  as  they  too  would  have  been  cleared  from 
the  knowledge  base. 


Another  possible  solution  Is  to  maintain  the  AMPEE  System  as  a  LISP 
suspended  Image,  lhus,  as  part  of  the  logout  procedure  from  the  AMPEE 
System,  a  new  suspended  Image  would  be  created  that  would  be  written  to  t  new 
version  of  the  same  file  that  was  resumed.  If  for  some  reason,  an  abnormal 
termination  occurred  during  the  execution  of  the  AMPEE  System,  and  normal  end 
of  processing  was  not  performed,  the  work  of  the  entire  session  would  be  lost 
because  the  new  suspended  Image  would  not  be  created. 

Oependlng  on  the  type  of  usage  that  Is  foreseen  (especially  for  the 
prototype  version),  this  may  not  be  such  a  drawback,  for  Instance,  If  little 
updating  will  be  performed  to  global  knowledge  bases  (e.g.,  the  catalog  or 
the  requirements  database)  then  generally  not  much  data  would  be  lost  In  the 
event  of  an  abnormal  termination. 

4.  EVALUATION  OF  ART  WITH  RESPECT  TO  THE  PROBLEM  DOMAIN  (The  AMPEE  System) 

Because  AR1  Is  an  expert  system  development  tool.  It  Is  suitable  for  the 
development  of  expert  systems  In  any  problem  domain,  lhus.  In  addition  to 
evaluating  AR1  Itself,  the  expert  system  developed  using  ART  must  also  be 
evaluated  for  Its  suitability  to  the  problem  domain.  In  the  paragraphs  that 
follow,  the  evaluation  criteria  and  Issues  Identified  In  Section  III  will  be 
applied  to  the  system  proposed  under  the  CAMP  study.  These  Issues  and 
evaluation  criteria  are  summarized  In  Figure  32. 

The  AMPEE  System  does  support  the  reuse  of  pre-bullt  Ada  software  parts 
for  use  In  the  area  of  missile  flight  software,  but  the  prototype  design  does 
not  call  for  an  automatic  means  of  enforcing  reuse.  Reuse  Is  supported  at 
the  requirements  and  design  level  via  the  use  of  schematic  parts.  Reuse  at 
the  code  level  takes  place  through  the  reuse  of  simple  and  generic  parts. 

Code  efficiency  Is  very  Important  In  the  AMPEE  System.  There  are  two  places 
where  this  comes  Into  play: 

The  simple  and  generic  parts  are  coded  as  efficiently  as  possible. 
Efficiency  rules  are  Incorporated  Into  the  part  constructors  to 
facilitate  the  production  of  efficient  code. 

The  technology  used  In  the  AMPLE  System  has  emerged  from  the  laboratory 
and  Is  now  commercially  available,  but  It  Is  still  considered  an  emerging 
technology  area.  The  system  Is  designed  to  be  flexible  and  easy  to  maintain 
In  order  to  Incorporate  future  technological  advances. 
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Automation  Is  provided  In  the  areas  of  part  Identification  and  location, 
and  In  the  generation  of  tailored  software  components  from  meta-parts. 

Further  automation  can  be  Incorporated  as  It  becomes  feasible. 

The  AMPEE  System  Is  targeted  for  the  missile  flight  software  domain, 
thus,  little  Is  required  when  the  system  Is  delivered.  The  catalog  of  parts 
Is  easily  updated,  thus  the  addition  or  deletion  of  parts  to  the  system  Is 
easily  accomplished. 

lhe  user  will  Interface  to  the  AMPEE  System  via  menus  and  a  limited 
natural  language  dialog.  Each  major  facility  (l.e.,  the  catalog,  parts 
Identification,  and  component  constructors)  will  be  directly  accessible  to 
the  user.  It  Is  expected  that  the  system  will  be  usable  by  both  software 
engineers  and  domain  engineers.  User  training  requirements  will  be  developed 
In  the  next  phase  of  CAMP. 

The  user  will  be  prompted  for  specifications  for  the  software  component 
under  construction.  The  specifications  provided  by  the  user  will  be  analyzed 
for  consistency  and  completeness.  The  transformation  of  these  specifications 
Into  different  forms  (e.g.,  program  design  language,  text,  graphical  form)  Is 
not  a  feature  that  will  be  provided  Initially,  although  It  Is  a  desirable 
feature  of  this  type  of  system. 

The  component  constructors  will  produce  correct  Ada  code  that  will  have 
efficiency  built  Into  It,  but  facilities  are  not  provided  for  proving  the 
correctness  of  the  code.  The  size  of  the  AMPEE  System  and  the  storage  and 
response  times  are  Indeterminate  at  this  time  (see  References  44  and  45). 


REUSABILITY 


•  IS  THE  REUSE  OF  PRE  BUILT  PARTS  SUPPORTED? 

•  AT  WHAT  LEVEL  IS  REUSE  SUPPORTED  (e.g.,  REQUIREMENTS,  DESIGN, 
CODE)  AND  MAINTENANCE  PERFORMED? 

•  IS  REUSE  OF  PRE  BUILT  PARTS  ENFORCED? 

ADA  AND  THE  PROBLEM  DOMAIN 

•  IS  ADA  SUPPORTED?  (i.e.,  CAN  ADA  PARTS  BE  GENERATED?) 

•  IS  THE  PROBLEM  DOMAIN  le  g  .  MISSILE  FLIGHT  SOFTWARE) 

ADDRESSED? 

•  IS  THE  CODE  PRODUCED  EFFICIENT  ENOUGH  FOR  THE  PROBLEM  DOMAIN? 

TECHNOLOGY 

•  IS  THE  TECHNOLOGY  OF  SUFFICIENT  MATURITY  FOR  INCORPORATION  INTO 
AN  AUTOMATED  SOFTWARE  GENERATION  SYSTEM? 

•  WHAT  DEGREE  OF  AUTOMATION  IS  PROVIDED? 


SYSTEM  INITIALIZATION  MAINTENANCE 

•  WHAT  IS  REQUIRED  WHEN  THE  SYSTEM  'COMES  IN  THE  DOOR'?  <U.,  IS 
DOMAIN  ANALYSIS  REQUIRED?  MUST  A  DOMAIN  SPECIFIC  LANGUAGE  BE 
DEVELOPED?  DOES  EXISTING  CODE  NEED  TO  BE  RESTRUCTURED?  DO 
SOFTWARE  PARTS  NEED  TO  BE  PRE-BUILT  FOR  LATER  USE?) 

•  IS  THE  SYSTEM  EASY  TO  MAINTAIN? 

•  CAN  THE  SYSTEM  EVOLVE  AS  TECHNOLOGICAL  ADVANCES  ARE  MADE? 


PHYSICAL  ATTRIBUTES  OF  THE  SYSTEM 

•  IS  THE  SYSTEM  A  REASONABLE  SIZE?  (i.a  ,  WHAT  ARE  ITS  BASIC 
STORAGE  REQUIREMENTS?) 

•  IS  THE  SYSTEM  EFFICIENT  IN  TERMS  OF  BOTH  STORAGE  AND  RESPONSE 
TIME? 


SPECIFICATION  TECHNIDUE  AND  THE  SPECIFICATION 

•  WHAT  TYPE  DF  SPECIFICATION  TECHNIDUE  IS  AVAILABLE?  (e  g  , 

FORMAL  SPECIFICATION  LANGUAGE?  NATURAL  LANGUAGE?  PROCEDURAL 
OR  NDN  PROCEDURAL?) 

•  IS  THE  SPECIFICATION  TECHNIOUE  APPROPRIATE  TD  THE  USER?  ARE 

Multiple  specification  technidues  provided  sd  that  the  mdst 

APPROPRIATE  ONE  CAN  BE  USED? 

•  WHAT  LEVEL  DF  EXPERTISE/TRAINING  IS  REQUIRED  TO  EFFECTIVELY 
INTERFACE  WITH  THE  SYSTEM? 

•  IS  THE  INTERFACE  TECHNIOUE  APPROPRIATE  TO  THE  PROBLEM  DDMAIN? 

•  CAN  THE  SPECIFICATION  BE  AUTOMATICALLY  TRANSFORMED  TO  A  FORM 
THAT  IS  COMPREHENSIBLE  TO  ALL  PARTIES  WHO  NEED  TO  KNDW> 

•  CAN  THE  SPECIFICATION  BE  PUT  IN  A  FORM  THAT  IS  ANALYZABLE 
(e.g..  FOR  COMPLETENESS,  CONSISTENCY,  CLARITY)? 

•  IS  THE  SPECIFICATION  MAINTAINABLE  (IF  THE  SPECIFICATION  IS  TO 
FUNCTION  AS  A  FORM  OF  DOCUMENTATION  AND  CONTROL,  IT  MUST  BE 
MAINTAINED  IN  A  CURRENT  STATE  THROUGHOUT  THE  SOFTWARE  LIFE 
CYCLE)? 


USER  SUPPDRT 

•  IS  THE  USER  ASSISTED  WITH  SPECIFICATIONS  (i.e  IS  PARTIAL 
SPECIFICATION  SUPPORTED?!? 

•  DOES  THE  SYSTEM  SUPPORT  AN  INCREMENTAL  DR  ITERATIVE  APPROACH  TO 
DEVELOPMENT? 

•  ARE  THE  SPECIFICATIONS  CHECKED  FOR  COMPLETENESS  CONSISTENCY, 
CLARITY? 

•  CAN  THE  USER  INTERFACE  DIRECTLY  WITH  THE  VARIDUS  COMPONENTS 
OF  THE  SYSTEM  le.g  ,  CAN  HE  DIRECTLY  QUERY  THE  PARTS  CATALOG?!? 


SYSTEM  OUTPUTS 

•  IS  OPTIMIZED  CDDE  PRODUCED? 

•  IS  THE  CDDE  VERIFIABLY  CDRRECT? 

•  ARE  FACILITIES  PROVIDED  TO  VERIFY  CORRECTNESS  OF  RESULTING 
MODULES  (e  g.,  AUTOMATIC  GENERATION  OF  TEST  PROCEDURE, 
CORRECTNESS  PRDOFSI 

•  ARE  SUPPORTING  DOCUMENTS  (e  g.,  ADI  SYSTEM  DOCUMENTATION) 
PRODUCED? 


5.  CONCLUSIONS 


During  the  evaluation  period  only  Beta  versions  of  ART  were  available  on 
the  VAX  (ART  was  released  on  the  Symbolics  In  March,  1985),  but  a  consistent 
Increase  In  quality  has  been  noted  during  that  time.  Although  ART  Is  not  yet 
a  mature  product,  and  as  such  suffers  from  some  of  the  drawbacks  of  systems 
that  are  newly  developed.  It  provides  a  high  degree  of  functionality  for  the 
application  under  consideration  In  the  CAMP  study.  It  Is  anticipated  that 
there  will  be  an  Improvement  In  efficiency  and  speed  of  the  system  which  will 
facilitate  system  development  and  make  ART  an  even  more  attractive  choice  for 
expert  system  development  on  VAX-based  systems.  Thus,  ART's  functionality 
coupled  with  Its  availability  on  VAX  equipment  and  the  Interest  of  Inference 
personnel  In  Improving  the  product,  lead  us  to  conclude  that  ART  Is  a  tool 
that  should  continue  to  be  used  In  the  CAMP  project. 


SECTION  VI 

SOFTWARE  PARTS  COMPOSITION  SYSTEM  CONCLUSIONS 


This  section  discusses  some  of  the  conclusions  reached  during  the 
software  composition/generation  study  portion  of  the  CAMP  project.  Volume  I 
contains  conclusions  that  relate  to  missile  software  commonality  and  the 
design  of  software  parts. 

The  development  of  a  universal  software  generator  system  Is  not 
practical  In  the  foreseeable  future.  Although  there  are  several  research 
efforts  underway  to  develop  application  Independent  systems  which  can 
generate  software  from  requirements,  these  systems  have  several  major 
drawbacks . 

a.  They  are  still  In  the  research  phase  of  development. 

b.  They  are  very  complex  to  use. 

c.  The  code  they  generate  Is  not  efficient  enough  for  real- time 
embedded  applications. 

Few  existing  software  generation  systems  are  capable  of  handling 
software  parts.  Most  of  the  work  being  done  In  the  area  of  software 
generation  assumes  that  a  new  software  system  will  be  generated  from 
scratch.  In  those  systems  which  do  account  for  reusable  components  (e.g.. 
Use. It),  the  parts  are  restricted  to  simple  functional  black  boxes.  No 
provision  Is  made  for  complex  parts  (e.g.  generic  and  schematic  parts). 

Formal  specification  languages  have  severe  drawbacks  as  Interface 
mechanisms  to  a  software  parts  composition  system.  Although  a  formal 
specification  language  Is  a  sound  technical  approach  to  specifying  software 
requirements  and  design  Information,  past  experience  has  shown  that  this  type 
Interface  mechanism  Is  very  poor  In  terms  of  comprehensibility.  In  effect, 
only  experts  can  read  and  understand  the  data  being  described.  Since  the 
goal  of  a  software  parts  composition  system  Is  to  simplify  the  use  of  parts, 
we  believe  that  this  approach  Is  not  fruitful. 

An  automated  software  parts  catalog  Is  an  essential  component  of  any 
successful  software  reusability  effort.  Given  that  there  Is  a  significant 
number  of  parts,  an  automated  tool  will  be  needed  to  help  manage  the  parts 
and  to  help  the  user  of  the  parts  analyze  them  for  suitability  for  his 


application.  If  parts  are  constructed  from  other  parts  (as  they  should  be) 
the  Interrelationship  of  the  set  of  parts  can  become  quite  complex.  An 
automated  tool  can  help  the  user  manage  this  complexity  and  Increase  the 
productivity  gained  from  using  the  parts. 

A  textual  software  parts  catalog  Is  an  essential  aspect  of  any 
successful  software  reusability  effort.  The  existence  of  an  automated 
software  parts  catalog  does  not  preclude  the  need  for  a  textual  version  of 
the  catalog.  There  will  be  organizations  which  for  some  reason  or  another 
will  not  have  access  to  the  automated  tool  and  will  need  Information  about 
the  parts.  Ideally,  the  automated  software  parts  catalog  will  be  able  to 
generate  the  textual  software  parts  catalog. 

The  early  Identification  of  software  parts  can  be  facilitated  by  an 
automated  tool.  A  critical  factor  In  the  successful  use  of  software  parts 
will  be  the  Introduction  of  the  parts  Into  the  software  system  early  In  the 
software  development  process.  In  other  words,  the  knowledge  that  software 
parts  will  be  used  (and  the  knowledge  of  what  parts  will  be  used)  will  have 
an  effect  on  the  design  of  the  software.  In  addition,  the  use  of  software 
parts  might  Impact  the  requirements  for  the  software.  This  case  might  arise 
when  the  existence  of  certain  parts  facilitates  a  certain  algorithmic 
approach  (e.g..  If  the  missile  guidance  engineer  Is  aware  of  the  existence 
of  a  wealth  of  parts  to  perform  an  operation  In  a  certain  manner,  he  might 
select  that  approach  to  reduce  costs).  The  parts  Identification  process  will 
map  system  (e.g.,  missile)  requirements  to  existing  software  parts  thereby 
allowing  early  Identification  of  applicable  software  parts.  This 
ldent 1 f Icat Ion  wll 1  also  facilitate  trade-off  analyses,  cost  estimates,  and 
sizing  and  timing  analyses. 

The  technology  exists  for  automating  the  construction  of  software 
components  from  design  paradigms.  The  concept  of  software  design  parts  has 
been  discussed  for  a  number  of  years  within  the  software  engineering 
community.  In  the  past,  most  researchers  have  adopted  a  template  view  of 
this  type  of  part.  In  other  words,  the  design  would  be  Implemented  by  means 
of  a  template  which  the  user  would  manually  complete.  Our  experience  on  CAMP 
Indicated  that  If  the  template  Is  supplemented  by  a  set  of  construction  rules 
then  the  construction  of  the  software  component  from  user -specified 
requirements  could  be  completely  automated.  We  have  termed  these  types  of 
parts  (template  plus  construction  rules)  schematic  parts. 


Expert  systems  have  a  high  potential  In  the  automation  of  the  software 
parts  engineering  process.  Expert  systems  are  typically  beneficial  In  areas 
which  have  eluded  solution  by  classical  programming  techniques  and  which  are 
currently  being  solved  by  human  experts.  This  Is  most  definitely  the  case  In 
the  use  of  schematic  parts  and  In  the  Identification  of  applicable  software 
parts.  Ourlng  CAHP  we  demonstrated  that  schematic  parts  can  be  effectively 
and  efficiently  generated  using  an  expert  system.  We  also  designed  a  system 
for  parts  Identification  using  an  expert  system.  Although  the  software  parts 
catalog  need  not  use  an  expert  system  (e.g.,  classical  data  base  management 
systems  can  be  used),  the  Incorporation  of  all  three  functions  Into  one  tool 
facilitates  Information  sharing. 


APPENDIX  A 

DEFINITION  OF  THE  CAMP  PARTS  CATALOG  ATTRIBUTES 


This  appendix  provides  a  detailed  explanation  of  each  attribute  of  the 
Ada  missile  software  parts  catalog  developed  under  the  CAMP  contract.  For 
each  attribute  the  following  Information  Is  provided  (as  applicable): 

(a)  The  name  of  the  attribute. 

(b)  The  data  type  of  the  attribute.  The  type  of  an  attribute  can  be 
STRING  (e.g.,  the  value  of  'Part  Id'  Is  a  string),  TEXT  (e.g.,  the 
value  of  'Abstract'  Is  of  type  TEXT),  ENUMERATION  (e.g.,  the  'Level' 
attribute  must  have  a  value  of  'simple',  'generic',  or  'schematic'), 
or  NUMERIC  (e.g.,  the  value  for  'Source  Size'  must  be  the  number  of 

I  Ines  of  code) . 

(c)  The  domain  of  an  ENUMERAUON  type. 

(d)  Ihe  status  of  the  attribute.  This  Is  either  REQU1RE0  (l.e.,  all 
parts  must  be  supplied  a  value  for  this  attribute)  or  RECOMHENOEO 
(l.e.,  the  attribute  Is  recommended  for  completeness  but  not 
required) . 

(e)  Where  useful,  an  example  of  an  attribute  value  Is  shown. 

(f)  The  description  of  the  attribute's  meaning. 

In  addition  to  the  above  Information,  attributes  whose  value  Is  dependent 
upon  the  scope  of  the  catalog  are  Identified,  and  the  differences  In  content 
are  elaborated.  Figure  A-l  enumerates  the  catalog  attributes. 


PART  ID 

VERSION 

ABSTRACT 

TYPE 

CLASS 

OPERATION 

KEYWORDS 

DEVELOPED  BY 

DEVELOPMENT  STATUS 

CATALOG  UNITS  W1THED 

USAGE 

SECURITY  CLASS  (PARTI 
LINES  OF  CODE  (SOURCE) 
REQUIREMENTS  DOCUMENTATION 
HARDWARE  DEPENDENCIES 
ACCURACY 


REVISION  ID 

NAME 

CATEGORY 

LEVEL 

INLINE 

PARAMETER  NAME 

DATE  CATALOGED 

DEVELOPED  FOR 

VERIFICATION  STATUS 

WITHING  UNITS 

LOCATION  OF  CODE 

SECURITY  CLASS  (CATALOG  ENTRY) 

FIXED  OBJECT  CODE  SIZE 

DESIGN  DOCUMENTATION 

OTHER  RESTRICTIONS 

TIMING  CHARACTERISTICS 


REMARKS 


ATTRIBUTE  NAME  .  Part  Id 

TYPE  .  String 

STATUS  .  Required 

EXAMPLE  .  1160 

DESCRIPTION  .  The  Part  Id  Is  a  non-semantlc  code  which  together  with 


the  value  of  the  Revision  Id  attribute  uniquely  Identifies  a  catalog  entry. 
The  Part  Id  Is  not  required  to  be  unique  (e.g.,  the  same  code  would  be  used 
for  all  revisions  of  a  given  part).  This  type  of  code  will  facilitate 
catalog  Implementation  by  providing  a  way  to  Identify  software  parts 
Independently  of  their  names  (e.g.,  different  developers  may  develop  parts 
with  the  same  name);  by  assigning  a  Part  Id  to  each  part,  all  of  these  parts 
can  be  kept  In  the  same  catalog.  There  are  currently  several  coding  schemes 
proposed  or  currently  In  use  to  Identify  software;  these  codes  are  used  to 
Identify  the  developer  and  the  software  product  (Reference  15).  We  propose 
that  the  Part  Id  merely  be  a  sequential  Identifying  number  assigned  to  the 
software  part  with  other  fields  being  used  to  convey  descriptive  Information. 


ATTRIBUTE  NAME  .  Revision  Id 

TYPE  .  String 

STATUS  .  Required 

EXAMPLE  .  A5 

DESCRIPTION  .  The  Revision  Id  Is  a  non-semantlc  code  used  to  uniquely 


Identify  revisions  of  a  particular  part.  This  code  together  with  the  Part  Id 
form  a  unique  key. 

ATTRIBUTE  NAME  .  Version 


TYPE  .  String 

STATUS  .  Required 

EXAMPLE  .  Wander  angle.  North  pointing 

DESCRIPTION  .  This  attribute  contains  a  brief  description  used  to 


differentiate  between  parts  that  have  the  same  name. 


ATTRIBUTE  NAME  .  Name 

TYPE  .  String 

STATUS  .  Required 

EXAMPLE  .  Missile  Launch  Platform 

DESCRIPTION  .  This  attribute  provides  a  brief,  but  not  necessarily 


unique,  descriptive  name  of  the  part  (e.g.,  a  package  may  have  more  than  one 
body.  In  which  case  both  bodies  would  have  the  same  name  but  they  would  be 
uniquely  Identifiable  by  the  combined  key  consisting  of  Part  Id  and  Revision 
Id). 


A1 TRIBU1E  NAME  .  Abstract 

TYPE  .  Text 

STATUS  .  Required 

DESCRIPTION  .  The  abstract  Is  a  brief  (300-500  words)  explanation  of 


the  purpose  and  functioning  of  the  part,  and  the  reason  for  original 
development  (Including  design  rationalization).  The  Naval  Research 
Laboratory's  Software  Cost  Reduction  Project  has  a  separate  entry  for  design 
Issues.  An  alternative  that  we  recommend  Is  to  Include  a  brief  reference  to 
design  Issues  In  the  abstract,  and  If  It  Is  thought  that  the  user  will 
require  further  Information,  he  should  be  referred  to  an  external  design 
document.  If  the  part  Is  being  revised,  the  originating  component  may  be 
referenced  for  this  Information,  but  the  abstract  must  contain  the  reason  for 
revision.  Information  on  reason  for  original  development  may  provide  Insight 
Into  the  appropriateness  of  a  unit  for  a  particular  application,  and  thus 
facilitate  reuse  of  parts;  the  DACS  software  catalog  contains  a  separate 
entry  for  this.  We  think  this  too  can  be  briefly  stated  In  the  abstract  and 
If  greater  detail  Is  required,  the  user  should  be  referred  to  an  external 
document,  lhe  level  of  detail  In  the  abstract  will  depend  upon  the  scope  of 
the  catalog;  It  Is  Intended  to  provide  the  user  with  a  quick  overview  of  the 
unit.  If  the  catalog  has  been  Incorporated  Into  an  automated  system,  the 
abstract  can  be  scanned  to  pick  up  keywords  or  phrases  when  the  system  Is 
performing  a  search  for  requested  parts. 


ATTRIBUTE  NAME  .  Category 

1YPE  .  Enumeration 

DOMAIN  .  see  Figure  A  2 

STATUS  .  Required 

DESCRIPTION  .  This  attribute  specifies  the  taxonomelrlc  classification 

of  the  part. 

ATTRIBUTE  NAME  .  Type 

TYPE  .  Enumeration 

OOMAIN  .  (package,  subprogram,  task) 

STATUS  .  Required 

DESCRIPTION  .  The  TYPE  attribute  specifies  the  Ada  program  unit  type 

of  the  software  part. 

ATTRIBUTE  NAME  .  Level 

TYPE  .  Enumeration 

DOMAIN  .  (simple,  generic,  schematic) 

S1ATUS  .  Required 

DESCRIPTION  .  The  LEVEL  specifies  the  abstraction  level  of  the  part. 

See  Volume  I,  Section  II  for  more  details. 

ATTRIBUTE  NAME  .  Class 

TYPE  .  Enumeration 

OOMAIN  .  (specification,  body) 

STATUS  .  Required 

DESCRIPTION  .  Ada  specifications  and  their  associated  bodies  have 

separate  entries  In  the  parts  catalog;  this  attribute  Is  used  to  Identify 
that  aspect  of  a  part. 

ATTRIBUTE  NAME  .  Inline 

TYPE  .  Enumeration 

STATUS  .  Required 

DOMAIN  .  (yes,  no,  N/A) 

DESCRIPTION  .  This  attribute  specifies  whether  the  part  has  been  set 

up  to  be  *  1 n 1 1 ned 1  or  not. 
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ATTRIBUTE  NAME  .  Keywords 

TYPE  .  Set  of  0  or  more  Strings 

STATUS  .  Recommended 

DESCRIPTION  .  This  attribute  contains  one  or  more  keywords  or  phrases 


that  can  be  used  to  locate  a  part.  Keywords  can  be  used  to  describe 
functionality  of  the  part,  or  task  area.  The  purpose  of  a  keyword  Is  to 
narrow  the  search  for  a  desired  component.  If  an  automated  catalog  scheme  Is 
utilized,  words  that  appear  In  the  abstract  need  not  be  repeated  here  as  they 
can  be  automat  leal ly  extracted  and  added  to  the  keyword  list. 


ATTRIBUTE  NAME  .  Date  Cataloged 

1 YPE  .  String 

STATUS  .  Required 

EXAMPLE  .  02  22  85 

DESCRIPTION  .  This  attribute  provides  the  date  that  the  original  part 


or  revision  was  cataloged.  A  standard  format  for  the  date  should  be 
establ Ished. 


ATTRIBUTE  NAME  .  Developer 

TYPE  .  String 

STATUS  .  Required 

EXAMPLE  .  McDonnell  Douglas  Astronautics  Co. 

DESCRIPTION  .  The  exact  Information  contained  In  this  entry  Is 


dependent  upon  the  scope  of  the  catalog.  For  Instance.  If  the  catalog  Is 
Intra  company,  knowledge  of  the  actual  Indlvtdual(s)  may  be  useful,  whereas 
If  the  catalog  Is  Inter  company,  knowledge  of  the  organization  may  be 
sufficient,  lhls  entry  should  contain  at  least  the  name  of  the  developing 
organization.  Other  Information  that  might  be  useful  Includes  the  address  of 
the  developer  and  a  phone  number  for  a  contact  person.  If  the  entry  Is  for  a 
revision,  the  modifier  should  be  Identified. 


ATI R I BUI L  NAME  .  Developed  For 

1 YPF  .  String 

STATUS  .  Recommended 

EXAMPLE  .  Tomahawk  (BGM  109AS)  Flight  Software 

DESCRIP1I0N  .  This  attribute  should  Identify  the  project  and  type  of 

software. 

ATTRIBUTE  NAME  .  Development  Status 

TYPE  .  Enumeration 

DOMAIN  .  (In  development,  complete,  verified) 

STATUS  .  Required 

DESCRIPTION  .  This  attribute  Indicates  the  development  status  of  the 


unit.  The  usefulness  of  such  an  entry  Is  dependent  upon  the  scope  of  the 
catalog.  For  Instance,  If  the  catalog  Is  for  all  Air  Force  software 
projects,  the  usefulness  of  knowing  the  stage  of  development  of  a  particular 
component  diminishes  greatly,  whereas  If  the  catalog  Is  being  used  within  a 
single  project  or  for  a  particular  contractor,  such  Information  may  be  of 
value.  The  DACS  software  catalog  contains  an  entry  for  this,  and  ANSI 
X3. 99-1981  recommends  the  Inclusion  of  this  attribute  In  program  abstracts. 


AT1RIBU1E  NAME  .  Verification  Status 

TYPE  .  Enumeration 

DOMAIN  .  (Internal,  external) 

STA1US  .  Recommended 

DESCRIPTION  .  Verification  of  the  units  Increases  user  confidence  and 


promotes  reuse  of  existing  parts.  This  Is  Illustrated  by  the  contrast  In 
usage  of  parts  supplied  by  a  computer  users  group  which  are  not  validated, 
and  those  supplied  by  an  organization  which  performs  extensive  testing,  e.g., 
IMSL .  The  entries  for  algorithms  presented  In  the  Collected  Algorithms  of 
the  CACM  also  provide  Information  on  verification;  the  name  of  the  certifying 
Individual  or  organization,  the  certification  method,  results,  and  remarks 
are  supplied.  The  major  Issue  surrounding  verification  and  validation  of 
parts.  Is  who  should  perform  this  operation.  User  confidence  Is  Increased 
when  an  Independent  or  external  organization  performs  the  verification,  but 


Verification  Status  (concluded) 

the  task  of  verifying  all  parts  may  become  monolithic  for  a  single 
organization.  Our  proposed  solution  Is  to  provide  Information  on  whether 
the  part  was  verified  Internally  or  by  an  external  organization.  This 
issue  Is  discussed  In  greater  detail  In  Section  II,  paragraph  6, 
Organizational  Factors. 


ATTRIBUTE  NAME  .  Catalog  Units  Wlthed 

TYPE  .  String 

STATUS  .  Required 

DESCRIPTION  .  This  attribute  contains  an  enumeration  of  other  units 


within  the  catalog  that  this  unit  'withes'  (units  Identified  by  Part  Id, 
Revision  Id,  Name,  and  Version. 


ATTRIBUTE  NAME  .  Wlthlng  Units 

TYPE  .  String 

STATUS  .  Required 

DESCRIPTION  .  This  attribute  contains  an  enumeration  of  other  units 

within  the  catalog  that  'with'  this  unit. 

ATTRIBUTE  NAME  .  Usage 

TYPE  .  String 

STATUS  .  Recommended 

DESCRIPTION  .  This  attribute  contains  an  enumeration  of  the  projects 


and  systems  that  use  this  particular  part.  This  should  also  include  the 
places  where  parts  generated  via  schematics  are  used.  The  usage  attribute 
aids  In  the  tracking  of  which  systems  have  'checked  a  part  out  of  the 


library'.  Such  an  entry  facilitates  maintenance  In  the  event  that  an  error 
is  found  in  a  part. 

ATTRIBUTE  NAME  .  Location  of  Code/Constructor 

TYPE  .  String 

STATUS  .  Recommended 

DESCRIPTION  .  This  entry  should  specify  the  file  name,  library,  and 


computer  system  where  the  part  Is  located;  the  part  'level'  determines 
whether  It  will  be  source  code  or  a  parts  constructor. 


ATTRIBUTE  NAME  .  Security  Classification  of  Part 

TYPE  .  Enumeration 

DOMAIN  . 

(Unclassified,  Confidential,  Secret,  lop_Secret) 

S1ATUS  .  Required 

DESCRIPTION  .  This  attribute  specifies  the  DOD  security  classification 

of  the  part. 

ATTRIBUTE  NAME  .  Security  Class  If Icat Ion  of  Catalog  Entry 

TYPE  .  Enumeration 

DOMAIN  . 

(Unclassified,  Confidential,  Secret,  Top_Secret) 

STATUS  .  Required 

DESCRIPTION  .  This  entry  specifies  the  security  classification  of  a 

part's  catalog  entry;  this  may  be  different  from  the  security  classification 


of  the  part  Itself. 


ATTRIBUTE  NAME  .  Operation 

TYPE  .  String 

S1ATUS  .  Recommended 

DESCRIPTION  .  This  attribute  Identifies  the  operations  that  are 

exported  by  the  part. 

ATTRIBUTE  NAME  .  Parameter  Name 

TYPE  .  String 

S1A1US  .  Recommended 

DESCRIPTION  .  This  attribute  Identifies  the  parameters  associated  with 


each  operation  Identified  In  the  'Operation'  field.  The  parameters  shall  be 
Identified  as  to  whether  they  are  'In',  'out',  or  'In/out'  parameters. 


ATTRIBUTE  NAME  .  Source  Code  Size 

TYPE  .  Numeric 

STATUS  .  Recommended 

DESCRIPTION  .  This  attribute  provides  the  size  of  the  Ada  part  In 


terms  of  lines  of  source  code  (LOC).  The  definition  of  LOC  must  be  provided 
when  the  catalog  Is  established. 


ATTRIBUTE  NAME  .  Fixed  Object  Code  Size 

TYPE  .  Numeric 

STATUS  .  Recommended 

DESCRIPTION  .  This  attribute  provides  the  fixed  (static)  size  of  the 

Ada  part  In  terms  of  bytes  of  object  code. 

ATTRIBUTE  NAME  .  Hardware  Dependencies 

TYPE  .  Text 

STATUS  .  Recommended 

EXAMPLE  .  15538  data  bus 

DESCRIPTION  .  This  entry  contains  an  elaboration  of  any  hardware 

dependencies  of  the  part  which  would  limit  Its  transportability. 

A1TRIBU1E  NAME  .  Requirements  Documentation 

TYPE  .  Text 

STATUS  .  Recommended 

DESCRIPTION  .  This  attribute  Identifies  the  requirements  documentation 

and  Indicates  Its  availability. 

ATTRIBUTE  NAME  .  Design  Documentation 

TYPE  .  Text 

STATUS  .  Recommended 

DESCRIPTION  .  This  attribute  Identifies  the  design  documentation  and 

Indicates  Its  availability. 

ATTRIBUTE  NAME  .  Restrictions 

TYPE  .  Text 

STATUS  .  Recommended 

DESCRIPTION  .  This  attribute  Indicates  any  usage  restrictions  such  as 

proprietary  rights  and  copyrights. 
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ATTRIBUTE  NAME  .  Remarks 

TYPE  .  Text 

STATUS  .  Recommended 

DESCRIPTION  .  This  field  Is  for  any  general  remarks  concerning  the 

part,  or  for  continuations  of  other  fields. 

A1 TRIBUTE  NAME  .  Accuracy 

TYPE  .  lext 

STATUS  .  Recommended 

DESCRIPTION  .  This  field  contains  Information  on  the  accuracy  or 


precision  of  numerical  results  computed  by  the  part.  If  this  Information  Is 
not  relevant.  It  should  be  left  blank. 


ATTRIBUTE  NAME  .  Timing 

TYPE  .  Text 

STATUS  .  Recommended 

DESCRIPTION  .  This  field  contains  Information  on  execution  time  for 


sample  Invocations  or  Instantiations  of  the  part.  The  run  time  conditions 
that  produced  the  timing  results  must  be  specified  In  order  to  make  this 
Information  relevant. 
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Figure  B-1.  The  Cataloging  Form 
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APPENDIX  C 

SAMPLE  DBMS  IMPLEMENTATION  OF  THE  CAMP  PARTS  CATALOG 


1.  Database  Schema  _  106 

2.  Database  Usage  .  108 

As  a  proof-of-concept ,  MDAC-STL  constructed  a  parts  database  using 

TM 

ORACLE  ,  a  state-of-the-art  relational  database  management  system. 

1.  DATABASE  SCHEMA 

The  parts  database  consists  of  6  tables.  They  and  their  associated 
attributes  are  shown  In  Figure  Cl.  Ihe  purpose  of  each  table  Is  described 
In  the  following  paragraphs. 

The  Parts  Table  contains  the  attributes  unique  to  each  cataloged  part 
(l.e.,  there  exists  a  one-to-one  mapping  between  attribute  values  and 
entitles).  This  Is  the  primary  table  In  the  database,  containing  the 
majority  of  the  Items  described  In  Appendix  A.  Ihe  Part  ID  and  Version  ID 
together  form  the  key  for  this  relation. 

The  Developer  Table  contains  Information  about  each  engineer  developing 
software.  The  Developer  ID  Is  the  key  for  this  relation.  This  Information 
Is  separated  from  the  Parts  Table  because  an  engineer  can  develop  more  than 
one  part;  data  redundancy  would  result  from  Including  this  Information  In  the 
Parts  Table.  Parts  and  Developers  are  bound  together  by  means  of  the 
Developer  ID  attribute  In  the  Parts  Table. 

Ihe  Project  Table  contains  a  list  of  parts  which  are  In  use  by  one  or 
more  projects,  and  an  Indication  of  which  projects  are  using  which  parts. 
There  Is  a  many  to-many  relationship  between  parts  and  part  users,  thus,  the 
project  Information  Is  kept  separate  from  the  Parts  table  to  avoid  data 
redundancy. 


TABLES  _ ATTRIBUTES 


PARTS 

Id 

Version 

Name 

Abstract 

Category 

Type 

Level 

Class 

Date  oF  Development 

Oeveloper 

Project 

SoFtware 

Development  Status 

VerlFIcatlon  Status 

Security  Class  oF  Part 

Security  Class  oF  Entry 

Source  Size 

Object  Size 

Hardware  Dependencies 

Documentation 

Restrictions 

Remarks 

Accuracy 

Timing 

DEVELOPER 

Id 

Name 

Department 

MOC  Component 

PROJECT 

Id 

SoFtware 

Part 

Version 

USAGE 

Usage  Mechanism 

Used  Part 

Used  Part's  Version 

Using  Part's  Version 

Using  Part 

KEYW0R0 

Word 

Vers  Ion 

Part 

NOISE 

Word 

Figure  C-l .  Oatabase  Schema 

The  Usage  Table  tracks  parts  that  either  'with'  other  parts  In  the 
catalog,  or  are  generated  From  another  part  In  the  catalog.  This  table  Is 
separated  From  the  Parts  Table  because  there  Is  a  many-to  many  relationship 
between  'wlthlng'  and  'wlthed'  parts. 
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The  Keyword  lable  contains  a  list  of  keywords  found  In  the  abstracts  of 
cataloged  parts.  Intrles  In  the  Keyword  Table  can  be  generated  In  two  ways: 

(1)  Explicit  entry:  A  user  can  specify  a  keyword  to  be  Included  In  the 
table  by  specifying  that  word  In  the  'Keywords’  section  of  the 
Missile  Software  Ada  Parts  Cataloging  form  (see  Appendix  B). 

(2)  Automatic  entry:  A  Keyword  Table  generation  program  will  examine 
the  abstract  of  each  cataloged  part  and  make  an  entry  for  each 
keyword  found.  A  keyword  Is  any  word  which  Is  not  found  In  the 
Noise  Table.  The  Noise  Table  Is  a  list  of  words  which  should  not  be 
Included  In  the  Keyword  Table  when  found  In  an  Abstract  (e.g., 

•and",  "the",  "a",  •not"). 

2.  DATABASE  USAGE 

Two  primary  Interfaces  can  be  developed  for  database  report  generation. 
The  first  Is  a  menu  driven  mechanism  for  generating  standard  reports,  based 
on  ORACLE'S  Interactive  Application  Facility  (1AF).  The  second  Interface  Is 
command  driven  and  uses  Structured  Query  Language  (SQL)  commands  to  access 
any  Information  In  the  database.  The  following  are  some  examples  of  the  use 
of  SQL  to  retrieve  Information  from  the  Ada  parts  catalog. 

EXAMPLE  1.  List  all  parts  which  are  currently  In  development: 

SELECT  ID.  VERSIONJO.  NAME 

FROM  PARTS_TABLE 

WHERE  DEVELOPMENT_STATUS  *  "IN  DEVELOPMENT" 

EXAMPLE  2.  List  all  parts  which  'with'  part  called  BINARY_TREE : 

SELECT  USTNG_PARTJD,  USING_VERSION  JO 

FROM  USAGE .TABLE 

WHERE  l'SF.D_PART_IO"USED_VERSION JO  » 

(SELECT  10"VERSI0N  JD 
FROM  PAR TSJ ABLE 
WHERE  NAME  *  "BINARY  1REE") 


APPENDIX  D 

THE  FINITE  STATE  MACHINE  CONSTRUCTOR 


1.  Introduction  .  110 

2.  FSM  Constructor  Requirements  .  11? 

3.  FSM  Constructor  Top-Level  Design  .  114 

4.  Implementation  of  the  Proof-of-Concept 

FSM  Constructor  .  117 


1 .  INTRODUCTION 

A  finite  state  machine  (FSM  or  finite  automaton)  Is  an  abstraction  that 
can  be  used  to  model  software  systems  or  portions  of  software  systems  that 
consist  of  a  number  of  distinct  states  and  stimuli  or  events  that  cause  a 
change  In  or  transition  between  those  states.  An  FSM  has  one  state  that  Is 
designated  as  the  Initial  or  beginning  state.  This  Is  the  state  at  which 
processing  begins.  A  terminal  or  end  state  Is  a  state  at  which  processing 
ends  (l.e.,  there  are  no  transitions  out  of  that  state).  Transitions  between 
the  states  of  the  FSM  are  caused  by  stimuli  or  events.  A  transition  Is 
dependent  upon  the  current  state  at  the  time  the  event  occurs  (l.e.,  the  same 
stimuli  applied  In  two  different  states  In  the  same  FSM  may  result  in  two 
different  transitions).  Figure  D-l  depicts  a  typical  graphical 
representation  of  a  finite  state  machine. 


Figure  D-l.  A  Finite  State  Machine 
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There  are  several  variations  of  the  basic  finite  state  machine.  For 
example,  actions  can  be  associated  with  the  transitions  between  states  or 
with  the  states  themselves. 

Finite  state  machines  are  a  useful  representation  for  a  number  of 
different  types  of  software  that  arise  In  the  missile  flight  domain  (e.g., 
launch  control  software,  signal  processing). 

As  part  of  the  CAMP  study,  MDAC  developed  the  requirements  specification 
and  top  level  design  of  a  prototype  software  parts  engineering  expert  system 
known  as  the  Ada  Missile  Parts  Engineering  Expert  (AMPEE)  System  (see 
References  44  &  45).  This  system  Incorporates  a  facility  for  component 
construction  that  provides  the  user  with  the  ability  to  construct  (l.e., 
tailor  or  Instantiate)  meta  parts  (l.e.,  schematic  or  generic  parts)  found  In 
the  Ada  missile  software  parts  catalog.  The  Component  Construction  facility 
Is  Intended  to  consist  of  a  constructor  for  each  schematic  part  and  for  some 
generic  parts  (constructors  will  only  be  developed  for  generic  parts  that  are 
sufficiently  complex).  The  Finite  State  Machine  Constructor  Is  one 
constructor  that  will  form  a  part  of  the  AMPEE  System. 

A  number  of  reasons  exist  for  developing  a  schematic  part  and  part 
constructor  for  a  finite  state  machine. 

Finite  state  machines  occur  frequently  within  the  operational 
missile  flight  software  domain. 

The  part  Is  very  straight-forward  to  build,  but  certain  variations 
cannot  be  captured  via  the  Ada  generic  facility  (e.g.,  actions 
associated  with  state  transitions). 

Providing  a  schematic  part  relieves  the  software  developer  of  the 
tedium  of  building  a  fairly  simple  piece  of  software,  and  provides 
an  error  free  Implementation  based  on  his  specifications. 

R  J  A  Buhr  (Reference  39)  summarized  the  need  for  a  standardized  Implementa¬ 
tion  In  the  following  way: 

•  finite  state  machines  are  ubiquitous  In  many  types  of 
embedded  systems.  Accordingly,  their  explicit,  consistent, 
and  uniform  representation  In  the  Ada  program  text  seems 
desirable,  both  for  verifiability  and  readability.* 


The  Implementation  of  the  Finite  State  Machine  Constructor  served  two 
purposes : 

It  served  as  a  proof -of -concept  for  providing  a  semi  automated  means 
of  generating  missile  flight  software. 

It  provided  a  means  for  evaluating  ART,  the  expert  system 
development  tool  discussed  In  Section  V. 

In  the  paragraphs  that  fellow,  the  requirements,  design,  implementation, 
and  efficiency  considerations  are  discussed. 

2.  FSM  CONSTRUCTOR  REQUIREMENTS 

The  Finite  State  Machine  Constructor  forms  a  part  of  the  Component 
Generation  function  of  the  Ada  Missile  Parts  Engineering  Expert  System.  It 
is  a  domain-independent  schematic  part  that  provides  the  user  with  an 
automated  means  of  generating  a  finite  state  machine  software  component.  An 
Ada  package  is  created  that  contains  a  procedure  to  process  Incoming 
stimuli.  A  function  is  also  provided  that  allows  the  current  state  to  be 
determined . 

The  Finite  State  Machine  Constructor  requires  the  use  of  both  the  ART 
programming  language  and  LISP. 

a.  Interface  Requirements 

The  FSM  Constructor  Is  required  to  Interface  to  the  VAX  file  system 
In  order  to  access  the  fixed  portions  of  code  used  In  the  component 
construction  process,  and  write  the  FSM  component  that  Is  output  from  this 
constructor.  File  access  is  handled  via  LISP  Input/output  facilities. 

b.  Functional  Requirements 

The  functional  requirements  of  the  FSM  Constructor  are  discussed  In 
the  following  paragraphs. 


The  user  supplied  Inputs  are  enumerated  below. 

—  File  Name:  The  name  of  the  file  where  the  component  Is  to 
be  written;  must  be  a  valid  file  name. 

--  Process  Name:  An  Ada  Identifier  that  will  Identify  the 
package  to  be  constructed. 

Initial  State:  The  Initial  state  of  the  finite  state 
machine. 

-  States :  The  valid  states  within  the  finite  state  machine. 
Transitions :  The  transitions  associated  with  each  state. 
Stimuli:  The  stimuli  that  result  In  the  transitions 
associated  with  each  state. 

Actions :  Ihe  actions  (If  any)  that  are  associated  with  the 
transitions  between  states;  this  Is  In  the  form  of  a 
package  name  and  the  procedure  within  the  package  that 
performs  the  requested  action. 

All  states,  stimuli,  and  actions  provided  by  the  user  must  be 
valid  Ada  Identifiers. 

System  supplied  Inputs  are  as  follow. 

-  Ada  Hlsslle  Parts  Catalog:  This  Is  used  to  determine  the 
location  of  the  fixed  portions  of  code  that  are  used  In  the 
construction  of  a  component  for  the  user. 

FSH  Construction  Rules:  These  are  the  rules  that  guide  the 
construction  of  the  component. 

(2)  Processing 

Ihe  FSH  Constructor  prompts  the  user  to  enter  the  required 
Inputs.  These  Inputs  are  edited  for  conformance  to  format  and  other 
constraints.  If  the  Input  data  passes  all  consistency  and  format  checks,  an 
Ada  component  Is  constructed  and  written  to  the  file  specified  by  the  user. 


(3) 


Outputs 


The  FSM  constructor  outputs  the  Ada  code  that  Implements  the 
FSM  specified  by  the  user.  Ihls  output  Is  directed  to  the  file  specified  by 
the  user. 

c.  Quality  Factors 

There  are  several  areas  that  must  be  addressed  when  considering  the 
quality  requirements  for  the  FSM  Constructor.  Correctness  of  the  Ada  code 
produced  Is  of  the  utmost  concern  In  the  development  of  part  constructors 
within  the  AMPEE  System.  As  was  pointed  out  In  the  main  portion  of  this 
report,  a  few  encounters  with  bad  parts  could  destroy  much  of  the  reusability 
effort.  This  constructor  must  not  only  produce  correct  Ada  code.  It  must  do 
so  consistently.  Although  It  Is  Important  that  the  FSM  Constructor  operate 
efficiently.  It  Is  of  greater  Importance  that  the  code  produced  by  the  FSM 
constructor  be  efficient. 

Usability,  flexibility,  and  maintainability  are  other  quality 
concerns  that  must  be  addressed.  The  Finite  State  Machine  Constructor  Is 
designed  to  be  easy  to  use;  the  user  will  be  prompted  for  the  required  inputs 
and  will  be  provided  with  the  appropriate  format.  Flexibility  and 
maintainability  are  two  concerns  of  the  entire  AMPEE  System. 

3.  FSM  CONSTRUCTOR  TOP-LEVEL  OESIGN 

Ihls  paragraph  discusses  the  top-level  design  of  the  Finite  State  Machine 
Constructor.  A  top-level  view  of  the  architecture  Is  presented  along  with 
the  functional  and  data  flow  for  this  portion  of  the  AMPEE  System.  Global 
and  local  data  are  also  discussed. 

a.  Architecture 

Figure  D -2  depicts  the  top-level  architecture  for  this  portion  of 
the  system.  As  can  be  seen  In  the  diagram,  the  AMPEE  System  Executive  (see 
Reference  45),  which  Is  Invoked  when  a  user  logs  Into  the  system.  Invokes  the 
Component  Construction  subfunction.  At  this  point  the  user  can  Invoke  any  of 
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the  available  component  constructors.  Control  Is  transferred  to  the  Finite 
State  Machine  Constructor  when  the  user  requests  this  part  and  It  Is  verified 
that  a  constructor  exists. 


Figure  0-2.  Architecture 


b.  Functional  Control  and  Data  Flow 


Figure  D-3  depicts  the  functional  control  flow  and  Figure  0-4 
depicts  the  data  flow  for  this  constructor. 


c.  Global  Data 


The  following  global  data  Is  utilized  by  the  Finite  State  Machine 
Constructor: 


Ada  Missile  Parts  Catalog:  This  Is  used  to  obtain  the  location 
of  fixed  portions  of  code  used  In  the  construction  of  the 
component . 

User  Id:  This  Is  used  to  tag  the  set  of  requirements  provided 
by  the  user. 
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d. 


Local  Data 


The  Finite  State  Machine  Constructor  makes  use  of  the  following 
local  data: 


FSH-User  Requirements:  This  Is  a  schema  that  Is  used  to 
capture  and  store  the  user's  requirements  for  a  specific 
Instance  of  the  finite  slate  machine  part.  These  requirements 
are  tagged  with  the  user's  Id  and  are  lime  stamped  In  order  to 
facilitate  their  retrieval  at  a  later  lime  (e.g.,  to  perform 
Component  Regeneration  see  References  44  and  45). 

Other  local  data  Includes  Intermediate  data  structures  used  In 
constructing  the  software  component  and  local  facts  used  to 
control  the  firing  of  rules. 


Figure  D-3.  Control  Flow 


Figure  0-4.  Oata  Flow 


4.  IMPLEMENTATION  OF  THE  PROOF-OF-CONCEPT  FSM  CONSTRUCTOR 

The  purpose  of  this  part  constructor  Is  to  provide  a  standard  design  for 
finite  state  machines.  It  was  desired  to  build  a  part  that  Is  flexible 
(e.g.,  actions  can  be  associated  with  the  state  transitions  If  the  user 
desires),  efficient  (e.g.,  dead  code  will  not  be  Introduced),  and  simple  to 
use  (e.g.,  the  user  doesn't  have  to  learn  a  high-order  specification  language 
In  order  to  use  this  part  constructor  successfully).  A  proof-of-concept 
Implementation  of  this  part  constructor  was  undertaken  to  prove  the 
feasibility  of  both  the  approach  ( 1 . e . ,  the  use  of  an  expert  system)  and  the 
tool  (l.e.,  ART). 


a.  The  Implementation 

The  Implementation  consists  of  both  ART  and  LISP  files.  The 
Individual  components  are  discussed  below;  Figure  D-5  provides  an  overview  of 
the  Implementation. 
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Figure  0-5.  Overview  of  Proof -of-Concept 
Implementation 

PROLOG. AR1 :  This  Is  an  ART  application  file  that  encompasses  a 

bare-bones  version  of  the  AMPEE  system  executive.  This 

component  assumes  Initial  control  when  the  system  Is  brought 

up.  It  performs  the  following  functions:  < 

(1)  Verifies  the  validity  of  the  user  requesting  AMPEE  System 
services 

(2)  Solicits  Identity  of  the  part  to  be  constructed 

(3)  Verifies  the  existence  of  the  part  In  the  Ada  missile  parts 
catalog 

(4)  Obtains  the  fixed  code  locations  from  the  catalog  entry 

(5)  Obtains  the  name  of  the  file  where  the  component  Is  to  be 
written 

CATALOG. AR1 :  This  component  contains  the  Ada  missile  parts 
catalog.  For  this  Implementation,  It  contains  only  the  basic 
catalog  schema  and  a  schema  for  the  Finite  State  Machine 
schematic  part.  No  processing  Is  performed  by  this  component. 
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FSH.ART:  This  Is  the  AR1  file  that  contains  the  actual  FSM 
Constructor;  It  performs  the  following  functions: 

(1)  Solicits  user  Input  to  construct  an  Instantiation  of  the 
finite  state  machine  part 

(?)  Creates  a  schema  to  store  the  component  requirements 
specified  by  the  user 

(3)  Performs  consistency  checks  and  constructs  Intermediate 
data  structures  (through  the  Invocation  of  LISP  routines) 

(4)  Generates  the  FSM  component  specified  by  the  user 

--  LFSH.LSP:  This  Is  a  LISP  file  that  contains  utilities  that 
construct  various  Intermediate  data  structures  used  In  the 
construction  of  the  finite  state  machine  component,  perform 
error  checking  of  the  data  provided  by  the  user,  and  write  out 
the  majority  of  the  Ada  component. 

b.  Expert  Features 

The  Finite  Stale  Machine  Constructor  Incorporates  a  number  of 
features  (l.e.,  the  smarts  or  optimisations)  that  contribute  to  the 
efficiency  and  flexibility  of  the  Ada  code  that  Is  produced.  These  features 
contribute  to  the  generation  of  Ada  code  that  Is  as  good  as  that  produced  by 
an  expert  Ada  programmer. 

The  user  Is  provided  with  the  expected  format  of  the  Input 
data.  This  type  of  assistance  makes  the  part  usable  by  a  wide 
range  of  personnel . 

Redundant  state  transitions  are  eliminated  from  the  Input 
(l.e..  If  the  beginning  state  and  ending  states  are  the  same 
for  two  sets  of  transitions,  then  the  stimuli  will  be  combined 
and  only  one  state  transition  will  appear),  lhls  Is  one  means 
of  preventing  the  Introduction  of  redundant  code  In  the 
component . 


Checks  are  made  for  non  determinism  In  the  state  transitions 
(e.g..  If  for  two  sets  of  state  transitions,  the  beginning 
states  are  the  same  and  the  stimuli  are  the  same,  but  the 
ending  states  are  different,  then  a  data  error  Is  signaled). 

A  decision  to  use  a  case  statement  or  an  if  then  else  statement 
Is  based  on  the  number  of  alternatives .  Some  work  Is  currently 
In  progress  to  determine  at  what  point  a  case  statement  becomes 
more  efficient  than  an  If-then  else  statement.  As  yet,  no 
results  have  been  obtained,  but  the  decision  point  Is  easily 
changed. 

A  check  Is  made  to  determine  If  a  stimuli  does  not  result  In  a 
transfer  out  of  the  present  state.  If  a  transfer  does  not 
occur,  then  a  re  ass Ignment  of  the  current  state  will  not  be 
made.  This  prevents  the  Introduction  of  extraneous  code  Into 
the  constructed  component. 

c.  User-System  Interaction 

The  following  sections  provide  a  sample  of  an  Interactive  session 
with  the  system,  and  the  output  from  that  session  (l.e.,  the  generated 

1  component).  The  compilation  listing  of  the  generated  Ada  component  Is 

provided  In  paragraph  (3). 

The  scenario  for  this  Interactive  session  Is  as  follows. 

|  --  The  user,  desiring  to  build  a  finite  state  machine 

representation  for  missile  firing,  elects  to  use  the  AHPtE 
System  Finite  State  Machine  Constructor  to  facilitate  the 
implementation. 

I 

!  lhe  user  logs  In  and  Is  presented  with  a  series  of  menus  for 

facility  selection. 

I 

1 

I 
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After  selecting  the  Finite  State  Machine  Constructor,  the  user 
Is  prompted  to  provide  state-transition  Information,  l.e.,  the 
beginning  state,  the  stimuli  that  cause  transitions  from  that 
state,  the  ending  state,  and  any  actions  associated  with  the 
transition. 

When  the  user  has  entered  all  the  state-transition  Information 
associated  with  the  FSM  that  he  Is  building,  he  enters  'quit1. 
The  Ada  component  Is  then  generated  If  all  data  checks  are 


(1)  A  Sample  User  Session 

Dribbling  to  USERDISK3  : 1  PALM03  ]FTR.  LSP,  1 
Enter  User  Id-  u 207  21  5 

Ada  Missile  Parti  Engineering  Expert  System 

1)  Parts  Catalog 

2)  Parts  Identification 

3)  Component  Construction 

Please  enter  choice: 

#  3 


Component  Construction 

1)  Component  Generation 

2)  Component  Regeneration 

Please  enter  choice: 

*  1 

Component  Constructors 

1)  Finite  State  Machine 

Pleaae  enter  choice: 

*  1 


Part  ID:  aOOl 
Revision  ID:  0 

Enter  file  name  (pathname)  for  component:  "miasi le. ada" 
Enter  Component  Name:  miasile 
Enter  Initial  State:  a_0 

Enter  statea  and  tranaitiona  as  prompted  below. 

Events  are  to  be  entered  in  the  following  format: 

(event_l  event_2  ...  event_n) 

Actions  are  to  be  in  the  following  format: 

( <action_package>  <action_procedure>) 

If  no  actions  are  associated  with  the  transition  enter  NIL 

States  are  to  be  entered  as  symbols,  e.g.  ,  statc_l 


Beginning  State:  s_0 

Events:  (intent_to_  launch_cmd_recd ) 


Ending  State:  s_l 


Action:  (ap  launch_eount  dovn_  aeq ) 


Beginning  State:  *_1 
Event  a:  (tect_fai  luce,.!  ) 

Ending  State:  a_n 

Action:  (ap  ahutdovn_abort_aeq ) 


Beginning  State:  a_l 
Eventa:  (all_teata_paaaed_l) 

Ending  State:  a_2 

Action:  (ap  £irat_not ion_aeq ) 

Beginning  State:  a_2 

Eventa:  (teat  failure_2_ 

) 

Error  -  Invalid  Ada  identifier  entered  at 
Eventa:  ( teat_f ai lure_2) 

Ending  State:  a_n 

Action:  (ap  ahutdown_abort_eeq) 

Beginning  State:  a_2 

Eventa  :  (pa aaed_  launcher_c  lear_  teat ) 

Ending  State:  a_3 

Action:  (ap  f in_deploy_aeq) 

Beginning  State:  e_3 
Eventa:  (all_teat_paaaea_2)  r 
Ending  State:  a_4 
Action:  (ap  vinga_out_early) 

Beg  inning  State:  a_A 

Eventa:  (thruat_decay_detected) 

Ending  State:  a_S 

Action:  (ap  ayaten_off_aeq) 


'  »  *  ■  *  M  ••  *  »  '  ’  .1 


--  V 


p  -J*  -jk  -V*»  •'-*  J-’-T 
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Beginning  State:  quit 
Data  passed  nd  check 

Data  passed  check  for  unreachable  states. 
Constructing  component  MISSILE 
No  applicable  rules. 

Ending  run. 

NIL 

ART1.0  Lisp>  (dribble) 
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(2)  The  Generated  Ada  Component 


with  AP; 

package  MISSILE  ia 

type  Stated  ia  (S.2,  S.3,  S_0,  S.J,  S.A,  S_l,  S.N); 

type  St  mull  ia  < TEST.FAILURE.2,  INTBIT.  TO.LAUNCH.CMD.AECD,  PASSED. LAUNCH  El. CLEAR. TEST,  THRUST. DECAT 
DETECTED, 

ALL.TESTS.PASSED.l,  TEST. FAILURE.  I ,  ALI^TEST.PASSES.2) ; 
function  Current.State  return  Statea; 
procedure  Signal  (Event  .  in  Stiauli); 

I nva  1  id. St liu  1  i  .  EXCEPTION; 
end  HISS1LE. 

package  body  MISSILE  ia 

Preaent.State  :  Statea  : ■  S.O; 

Lvent  ■  Stiauli; 

function  Current.State  return  atatea  ia 
begin 

return  Preaent.State; 
end  Current.State, 


procedure  Signal  (Event  :  in  Stiauli)  ia 
begin 

caae  Preaent.State  ia 
when  S.O  ■> 

if  (event  -  INTENT. TD_UUNCH.CMD.RECD)  then 
AP.UUNCH_CDUNTDOWN.SEQ; 

Preaent.State  :  ■  S.l; 
elae 

raiae  Invalid.St iauli; 
end  if; 

when  S.2  ■> 

if  (event  •  PA  SS  ED.  UU  NCH  ER_  CL  EAR.  TEST)  then 

AH.  FIN.DEPLDY.SEQ ; 

Preaent.State  :■  S.3; 
elaif  (event  ■  TEST.FAILURE.2)  then 
AP.  SHU  XDOWN.ABORT.SEQ; 

Preaent.State  :■  S.N; 
elae 

raiae  Invalid.Stiauli; 
end  if, 

when  S.4  ■> 

if  (event  -  THRUST.DECAY. DETECTED)  then 

AP.  SYSTEH.DFF.SEQ; 

Preaent.State  :■  S.5; 
elae 

raiae  Invalid.Stiauli; 
end  if ; 

when  S.l  •> 

if  (event  ■  ALL.TESTS. PASSED.  1)  then 
AP.  FIRST. MDT10N.SEQ; 

Preaent.State  :•  S.2; 
elaif  (event  -  TEST.FAILURE.t)  then 
AP.  SHUTDOWN.  ABDRT.SEQ; 

Preaent.State  :■  S.N; 
elae 

raiae  Invalid.Stiauli; 
end  if ; 

when  S.3  ■> 

if  (event  -  ALL. TEST. PASSES. 2 )  than 
AP.  WINCS  DUT  EARLY" 


(3)  The  Compiled  Ada  Component 


MISSILE  10-Sep-l 985  08:57:44  VAX  Ads  VI. 

Page  1 

D1  10-Se p-1985  08:43:51  USERDISK3:( 

M 03 1  Ml SSILE. ADA , 1  (1) 

1  with  AP; 

2  package  MISSILE  is 

3  type  State!  i»  (S_2,  S.3,  S.0,  S_5,  S_4,  S_I,  S.N); 

4  type  Stimuli  ii  (TEST.  FAlLURE_2,_INTENT_T0r  LAUNCH.  CMD.RECD,  PASSED. LAUNCHER. CLEAR. TEST,  T. 
ST.  DECAY.  DETECTED, 

5  ALL.TESTS. PASSED.  1 ,  TEST. FAILURE.  1 ,  ALL. TEST. PASSES. 2 ) ; 

6  function  Current.State  return  States: 

7  procedure  Signal  (Event  :  in  Stimuli); 

e  Inval  id.  Stimuli  :  EXCEPTION; 

9  end  MISSILE; 

PSECT  MAP 

Ptext  Hex  Size  Dec  Size  Name 

0  D0000006  6  MISSILE.,  SCO DE 

1  OOOOOG'O  16  MISSILE..  SCONSUNT 


lADAC-I -CL. ADDED,  Package  specification  MISSILE  added  to  library 


LIBRARY  SUMMARY 
USEr.DI SK3 :  [ PAL:: 03. CAMP. LIB) 
Unit  name 


AP 


Nodes  Percent  Blocks 
read  read 

4  40  4 


Unit  kind 

Package  specification 


F  V  'J  ■  .  *  J  ^ 


■_*v 


'WFf'p^'ri"^ 


PI 

i:l  SS  ILL 

10-Sep-1985 

08:57:47 

VAX  Adt  VI.  i  4 

>  * 

Page  2 

Ol 

10-Sep-l 985 

08:43:  51 

USERDISK3 ; ( l  ) 

X 

M031  MISSILE.  ADA  ;1  (1) 

!.'■ 

10 

11  package  body  MISSILE  is 

a 
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13 
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15 

16 

17 
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29 
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31 
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33 

34 

35 

36 

37 
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40 

41 

42 

43 

44 
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55 

56 

57 

58 

59 
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61 
62 

63 

64 

65 

66 


L-S- 


L’‘- 


S_0; 


Present_State  :  States 
Event  :  Stimuli; 

function  Current_State  return  statea  is 
begin 

return  Present_State; 
end  Current_State; 


procedure  Signal  (Event 
begin 


in  Stimuli)  is 


case  Present_State  is 
when  S_0  “> 

if  (event  -  INTENT.  TO_LAUNCH_CMD_R£CD)  then 
AP.  LAM1CH.C0UNTD0WN.SEQ ; 

Preaent_ State  :-  Sjl; 
else 

raise  Invalid.Stimuli ; 
end  if; 

when  S_2  »> 

if  (event  -  PASSED. LAUNCH ER_CLEAR_ TEST)  then 
AP.  FIN_DEPLOY_SEQ ; 

Preaent_State  S_3; 
elaif  (event  -  TEST.FAILURE.2)  then 
AP.  SHUTDOWN. ABORT^SEQ; 

Presenc.State  :•  S_N; 
else 

raise  Invalid_Stimuli ; 
end  if; 

when  S_4  ■> 

if  (event  -  THRUST.DECAY_DETECTED)  then 
AP.  SYSTEM_OFF_SEQ; 

Preeent.Stete  :■  S_5; 
else 

raise  Inva  lid_Stimuli ; 
end  if; 

when  S_  1  *> 

if  (event  -  ALL_TESTS_  PASSED.  1)  then 

AP.  FIRST.  MOT  I  ON.  SEQ  ; 

Preaent.State  :■  S.2; 
elsif  (event  ■  TEST_FA1LURE  1)  then 
AP.  SHUTDOWN.  ABORT.SEQ; 

Preaent_State  :■  S_N; 
else 

raise  Invalid.Stimuli; 
end  if; 

when  S.3  ■> 

if  (event  -  ALL.TEST.PASSES.2)  then 

ap.  wings.  out.earlyT 

Preaent.State  S_4 ; 
else 

raise  Invalid.Stimuli; 
end  if; 
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MISSILE 

01 

M03]MISS1LE.  ADA;  1 


P«t«  3 

<1) 


67  when  other*  ■>  raise  invslid_stiouli; 

68  end  ease; 

69  end  Signal; 

70 

71  end  MISSILE; 


PSECT  MAP 


Paect  Hex  Site  Dec  Site 
0  000001  34  340 

1  00000004  4 


Naae 

MI  SSILE.SCODE 
MISSILE.  3 DATA 


10-Se  p-1985  08:37:47 
10-Sep-1985  08:43:31 


ZADAC-I -CL. ADDED.  Package  body  MISSILE  added  to  library 

Corresponds  to  package  specification  MISSILE  compiled  10-Sep-1963  08:37 


LIBRARY  SUMMARY 
USE1DISK3: (PALK03. CAMP. LIB) 
Unit  name 


Nodes 

raad 

27 

10 


Percent 


Blocks 

read 


Unit  kind 


VAX  Ads  Vl.l 
USERDISK3:  (I 


MISSILE 

AP 


100 

100 


10 


Package  specification 
Package  specification 


MISSILE 


VAX  Ada  VI.  I 


Page  4 

01  Ada  Compilation  Statiitica 

K03  ]  MISSILE.  ADA  ;1  (1) 

COHMAND  QUALIFIERS 

ADA/LIS  MISSILE.  ADA 


10-Sa p-1985  08:57:47 
10-Sep-1985  08:43:51 


QUALIFIERS  USED 

/CHECK/COPY_SOURCE/DEBUC-ALL/ERROR_LIHIT«30/LIST/NOMACHINE_CODE 

/nodiacnostIcs/library-adaSlib 

/NOTE_SOURCE/OPTJHIZE-TIHE/NOSHOW/NOSYNIAX_ONLY 

/UARNiNCS-(NOCOHPILATION_NOTES,STATUS-LIST\  SUPPLEMENTAL-ALL, UARNINCS-ALL,  WEAK 


COMPILER  INTERNAL  TIMINC 


Phase 

CPU 

Elapaed 

Page 

I/O 

aeconda 

seconds 

fault* 

count 

Initialization 

0.16 

1.44 

368 

24 

Paraer 

•  0.15 

0.18 

167 

1 

Static  semantics 

0. 16 

0.  89 

183 

6 

IL  general  ion 

0.25 

1.47 

242 

21 

Segment  tree 

0.13 

1.11 

130 

21 

Annotate  tree 

0.02 

0.02 

11 

0 

F low  ana  lysis 

0.02 

0. 02 

7 

0 

Linearize  tree 

0.07 

0.31 

86 

0 

Code  generation 

0.37 

1.06 

337 

0 

Optimizer 

0.11 

0.37 

120 

0 

Data  allocation 

0.01 

0.01 

1 

0 

Generate  code  list 

0.08 

0.27 

98 

0 

Register  allocation 

0.01 

0.01 

8 

0 

Peephole  optimization 

0.04 

0.17 

29 

0 

Write  object  module 

0.05 

0.  07 

35 

0 

DST  generation 

0.05 

0.06 

17 

0 

Listing  generation 

0.07 

0.43 

28 

7 

Compilation  library 

0.33 

2.J21 

202 

69 

Compiler  total* 

1.52 

7.78 

1547 

129 

COMPILATION  STATISTICS 


Weak  warning* : 
Warnings: 
Errors : 


Peak  working  set: 
Virtual  pages  used: 
Virtual  pages  free: 
CPU  Time: 

Elapsed  Time: 
Compilation  Complete 


2418 

4797 

65203 

00:00:01.52 
00:00:07.  78 


(2802  Linea/Hinute) 


USERDISK  3: l i 


WARNIKCS-ALL) 
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d.  Source  Code 

The  following  sections  provide  the  source  code  for  the  components 
that  comprise  the  proof-of-concept  Implementation  of  the  FSM  Constructor. 


I 
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(1)  CATALOG. ART 


This  component  contains  the  template  for  entries  In  the  Ada  missile  software 
parts  catalog.  It  Is  also  Intended  to  contain  all  of  the  catalog  entries, 
however,  for  the  proof-of-concept  Implementation,  only  one  partial  catalog 
entry  Is  provided. 


;#«VAX  (in-peckege  #L 'art-user) 
(def -viewpoint- 1 eve  Is) 


e******************************************** ******  ****** 

CATALOG  SCHEMA 

***************************  ************************  ****** 


;  Template  for  catalog  entries 
*  ——————————————— 

(def schema  part-entry 
(pert-id ) 

(reviaion-id) 

(name) 

(version) 

(securi ty-claaaif icet ion-part) 
(aecuri ty-classif icat ion-entry) 
(type) 

•(level) 

(cleaa) 

(inline) 

(cetegory) 

(keywords) 

(fixed-code- location) 

(operation 

( slot-how-meny  multiple-velues)) 
(verif ication-atetua) 
(dete-ceteloged ) 

(developed -by) 

(developed-for) 

( requirement s-documentet ion) 
(design-docuaentetion) 

( aire-aource) 

(siae-ob ject ) 

(eccurecy) 

( tiaing-charec ter izet ions) 

( herdvere-dependenc ies ) 
(otber-reatrictions) 

(cata  log-units-withed) 

( vi  thing  -cete  log-units) 

(abstrect) 

(remarks) 

(timestemp- last -revision)) 


;  Catalog  entriea  for  software  parts 

(defschema  *99 

(instance-of  part-entry) 

(part-id  eOOl) 

(reviaion-id  0) 

(type  subprogram) 

(f iied-code-locetion  "faml.ada")) 


(2)  PROLOG. ART 


This  component  contains  ART  code  that  handles  'front-end'  processing  that  Is 
required  regardless  of  the  facility  selected  by  the  user.  It  Is  from  here 
that  control  Is  transferred  to  the  selected  facilities. 


t 
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PROLOG  for  AMPEE  System 


Fsets  to  link  parts  to  schemata  that  will  store  user  inputs 


(deffacts  initial-links 

(build-response-link  aOOl  0  f sa-uaer-responses )) 


Valid  users 


200538  U201965  u203093  u20721S) 


sequence))) 


Schema  to  keep  track  of  which  part  is  to  be  built 


(defachema  part-to-bui Id 
(part-id) 

(revision-id) 

(to-build-from)  (sequence  of  files  from  which  fixed  portions  of  code 
;in  component  being  built  will  be  copied 


( to-bui  Id-at )) 


Clceri  the  icreen  end  prompts  u*er  to  log  in 


(defrule  initial ire-system 

-> 

(cell-out  ereee-page  1  1) 

(inert  (ueer-id  •( prompt-end-reed  #L' expression 
"Enter  Uier  Id:  ")))) 


;  Verifie*  that  thet  u»er  code  used  es  log-in  is  velid. 

(defrule  verify-user 
(user-id  ?uid) 

(schema  ?uid  (instence-of  velid-user)) 

•> 

(essert  (user-verified))) 


;  This  will  eventually  be  replaced  by  e  complete  menu;  it  currently 
;  goes  directly  to  the  'Component  Construction'  function. 

(defrule  which-function 
?*  <-  (user-verified) 

•> 

(retrect  ?x) 

(cell-out  erese-pege  1  1) 

(main-menu)) 


;  Prompts  user  for  the  identity  of  the  pert  thet  he  vents  to  construct. 
;  At  a  leter  dete  it  is  anticipated  thet  the  ueer  will  have  been 
;  provided  with  e  list  of  perts  A  will  select  one  rather  than  being 
l  prompted  in  this  fashion. 

;  Two  rules  ere  used  to  get  the  pert  id  end  revision  id  because  with 
;  Beta  3.  the  compiletion  resulted  in  the  order  of  the  prompts  being 
;  chenged. 

(defrule  vhich-pert-l 

(stete  component-construction  component-ganaretion) 

•> 


(tarpri) 

(essert 


(scheme  ‘(ganaym) 

(instence-of  pert-to-build) 

(pert-id  "(prompt-and-reed  #L':expraesion  "Pert  ID:  "))))) 
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(defrule  vhich-part-2 

(schema  Tx  (instance-of  part-to-build)  (part-id  TPI)) 

•> 

(terpri) 

(aaaert 


(schema  Tx 

(revision— id  ■»( prompt-end-read  :expreaaion  "Revision  ID: 


")))» 


Verifies  that  the  part  identified  does  indeed  exist  in  the  parta 
catalog. 

If  the  part  does  not  exist,  the  user  should  be  taken  back  to  the 
prompt  for  part  id/revision  id  or  be  allowed  to  exit. 


(defrule  verif y-e~istance 
(declare  (salience  100)) 


(schema  ?x 

(instance-of  part-to-build) 
(part-id  TPI) 

(revision-id  ?RI)) 


(cate 

((schema  Ty 

(instance-of  part-entry) 

(part-id  TPI) 

(revision-id  TRI)) 

•> 

(assert  (part-available  TPI  TRI))) 


(otherwise 

■  > 

(printout  t  t  "Specified  part  does  not  exist  in  the  parta  catalog.") 
(retract  7x)))) 


(defrule  get-f ixed-code-and-plaee-to-build 
Tx  <-  (part-available  TPI  TRI) 

(schema  TY 

(instance-of  part-to-build) 

(part-id  TPI) 

(revision-id  TRI)) 

(case 

((schema  T 

(instance-of  part-entry) 

(part-id  TPI) 

(revision-id  TRI) 

( fixed-code- location  Tfile-namee)) 

•> 

(assert  (schema  TY  (to-build-f rota  Tf i le-namet )) ) ) ) 


♦♦VAX  (in-peckage  #L'art-ueer) 


t*«***tt*ttt*tt*tt**tt«*M**t*t*t*tiMitnHtt«<*>i«Mtit**»tM**t***mm 

Finite  Stete  Machine  Pert  Cnnatructor 

This  pert  cnnetructor  eolicte  inforoetinn  from  the  user  concerning  the 
epecific  finite  etete  machine  that  ie  tn  be  built.  The  ueer'e  input  ie 
■tored  in  e  'reeponse'  echeme.  In  the  prototype  implementetinn,  the  neer 


requirement!  knowledge  beee  will  be  updeted  by  this  'reepnnee'  schema  in 
order  tn  fecilitate  component  regeneretion.  Once  ell  input  ie  received 
frnm  the  user,  the  fern  enmponent  ie  constructed. 


Reletinns:  Fects  esserted  intn  the  knnwledge  beee  ere  treated  as  relations. 
Undeclered  reletions  generete  warnings  at  compile  time,  thus  they  are 
declered  here. 


(defreletinn  creete-stetes-s lot 
(?t  ime) ) 

(defrelation  init-st-input 
(It  ime)) 

(defrelation  prompt 

(?PI  ? R I  ITIME  7SCH) ) 

(defreletinn  get-beginning-«time) 

(defreletion  initiel  aequence) 

(defrelation  nd-check 
(7 PI  7RI  ITIME) ) 

(defreletion  get-component-name 
( ? PI  7RI  7TIME) ) 

(defrelation  get-initiel-atate 
( 7 PI  7RI  7TIME) ) 

(defrelation  get-beginning-stete) 

(defreletion  beginning-stete 
(IBS)) 

(defrelation  get-events) 

(defreletinn  events 
( 7EVENTS)) 

(defrelation  get-ending-state) 

(defrelation  ending-atete 
( ?ES ) ) 

(defreletion  get-actions) 


(defreletion  ection 
(7ACTI0IO) 
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(dafrelation  arror 
(TERROR-TYPE)) 


(dafrelation  chack-f or-unraachabla) 

(daf ralation  axtract-aea 

(TPI  TRI  TTIHE)) 

(dafrelation  build-part 
(TPI  TRI  TTIHE)) 

(dafrelation  action-pc:kagaa 
(Tap)) 

(dafralation  beginning-atatea 
(Tall-baginning-atatea)) 


;  Thia  acheoa  tanplata  ia  uaad  to  atora  uaar  input  for  the  cooatructioo  of  a 
;  particular  fan  compooaot.  Tha  information  provided  it  atorad  for  futura  uaa 
i  (e.g. ,  if  tha  component  conatructad  ia  oot  aa  tha  uaar  wanted,  ha  can  make 
;  changaa  to  hia  input  vithput  haviog  to  ra-aotar  all  of  it. 


(dafachama  f am-uaer-raapooaaa 
(part-id) 

(raviaioo-id) 

(uaar- id) 

(tiaaatamp) 

(file-name)  ;oama  of  fila  where  compooaot  will  ha  vrittao 

(component-name)  ;oama  of  componaot  to  be  built 

(initial-atata) 

(atataa) 

(atata-tranai tiona)) 


;  Eatabliahaa  a  acheoa  for  tha  uaer'a  requirement*,  aod  aaaarta  a  fact  to 
;  initiate  aolieitation  of  thoae  requirement*.  It  it  initiated  only  aftar 
;  verification  that  a  part  cooatructor  axiata  for  tha  part  requaated  by  tbe 


(«««ert  (achema  -(geneym) 

(inatence-of  fem-ueer-reeponeee) 
(pert-id  TPI) 

(reviaion-id  7RI) 

(uaer-id  ?UID) 

(timeatemp  Ttime) 

(file-name  7fn))) 

(eaaert  (get -component -neme  7PI  7RI  TTIME))) 


(defrule  get-component-name 

Tx  <-  (get -component -neme  TPI  TRI  TTIME) 

(echeme  Tach 

(ioatence-of  f am-uaer-reaponaea) 

(pert-id  TPI) 

(reviaion-id  TRI) 

(timeatemp  TTIME)) 

■> 

(retract  Tx) 

(terpri) 

(bind  T component -name  (prompt -end-reed  #L' rexpreeaion 
"Enter  Component  Name:  ")) 

(if  (eymbolp  Tcomponent-name)  then 

-(if  (velid-ede-identif ier  Tcomponent-name)  then 
(eaaert 

(achema  Tach  (component-name  Tcomponent-name)) 
(get-initiel-atete  TPI  TRI  TTIME)) 

elae 

(printout  t  t  "Invelid  Ade  identifier  entered  for  component 
(eaaert  (get-component-name  TPI  TRI  TTIME))) 

elae 

(printout  t  t  "Component  name  muet  he  e  ejmhol.") 

(eaaert  (get-component-nene  TPI  TRI  TTIME)))) 


(defrule  get-initiel-atete 

Tx  <-  (get-initiel-atete  TPI  TRI  TTIME) 

(achema  Tach 

(inetence-of  t am-uaer-reaponaea) 

(pert-id  TPI) 

(reviaion-id  TRI) 

(timeatemp  TTIME)) 

»> 

(retrect  Tx) 

(terpri) 

(bind  Tinitiel-atete  (prompt-end-reed  #L*:expreaaion 
"Enter  Initiel  Stete:  ")) 

(if  (eymbolp  Tinitiel-atete)  then 

(if  (velid-ede-identifier  Tinitiel-atete)  then 
(bind  Taeq-etete  (aeqS  (liat  Tinitiel-atete))) 
(eaaert 

(echeme  Tach  ( initiel-atete  Tinitial-atete) 


(atstes  Tieq-ttate)) 

( ini t-st-input  7TIHE)) 

tilt 

(printout  t  t  "Initial  state  oust  be  e  valid  Ade  identifier.") 
(assert  (get-initie 1-state  TPI  TRI  7TIME))) 

se 

(printout  t  t  "Initial  state  must  be  e  symbol. ") 

(essert  (get-initiel-stete  TPI  TRI  7TIHE) ) ) ) 


Initiates  State-Transition  input  from  the  user 


(def rule  init iete-state-trsns-ioput 
Tx  <-  ( init-st-input  Itiae) 

(schema  7 

(instence-of  pert-to-build) 

(pert-id  TPI) 

(revision-id  TRI)) 

(schema  Tsch 

(instence-of  fsm-vser-respooses) 

(part-id  TPI) 

(revision-id  TRI) 

(tiaestaap  Ttiae)) 

■> 

(retract  Tx) 

(printout  t  t  "Enter  stetes  cod  trensitions  es  proapted  belov. ") 

(printout  t  t  "Events  ere  to  be  entered  in  tbe  following  format:") 

(printout  t  t  "  (event_l  events 2  ...  eveo^_o)") 

(terpri) 

(printout  t  t  "Actions  are  to  he  in  the  folloviog  foraet:") 

(printout  t  t  "  (<ectioo_package>  <actioo_procedure>)") 

(printout  t  t  "If  no  actions  ere  associeted  with  the  treositioo  enter  III") 
(terpri) 

(priotout  t  t  "States  ere  to  be  entered  ee  symbols,  e.g. ,  atet*_l") 

(terpri) 

(assert 

(prompt  TPI  TRI  7TIKE  TSCH) 

(get-beginning-stste) 

( initial-sequence))) 


Cets  the  beginning  state  for  e  stete-trensition 

Data  and  error  checking  is  performed  oo  the  input  supplied  hy  the  user 


(defrule  get-beginoing-state 

Tz  <-  (prompt  TPI  TRI  TTIHE  7SCB) 
Tx  <-  (get-beginniog-stete) 

-> 

(retract  Tx) 

(terpri) 

(printout  t  t  "Beginning  Itete:  " 


(bind  TBS  (read)) 

(if  (equalp  TBS  #L'quit)  then 
(retract  Tz) 

(aasert  (nd-check  TPI  TR1  Til HE)) 
elae 

(if  (and  (aymbolp  TBS)  (not  (null  TBS)))  then 
(if  (valid-Ada-identifier  TBS)  then 
(aaaert  (beginning-atate  TBS) 

(get-eventa)) 

elae 

(printout  t  t  “Invalid  Ada  identifier  entered  for  Beginning  State") 
(aaaert  (get-beginning-atate))) 

elae 

(printout  t  t  "Beginning  State  auat  be  a  ayabol  -  i.a. ,  not  a  liat") 
(aaaert  (get-beginning-atate)) ) )) 


Ceta  the  atimuli  aaaociated  with  a  atate-trenaition 


(defrule  get-eventa 

(declare  (aalience  100)) 

Tx  <-  (get-eventa) 

(beginning-atate  T) 

■> 

(retract  Tx) 

(printout  t  t  "Eventa:  ") 

(bind  TEVENTS  (read)) 

(if  #L(liap:liatp  T EVERTS)  then 

(if  (valid-liat-of-Ada-identifierr  TEVENTS)  then 
(bind  Taeq-eventa  (aeq*$  TEVENTS)) 

(aaaert  (eventa  Taeq-eventa) 

(get-ending -at at a)) 

elae 

(printout  t  t  "Error  -  Invalid  Ada  identifiar  entered  aa  an  event.") 
(aaaert  (get-eventa))) 

elae 

(printout  t  t  "Eventa  auat  be  entered  aa  a  liat  of  ayabola  (e.g. ,  (a  b  c))“) 
(aaaert  (get-eventa)))) 


Obtaina  the  ending  atate  for  a  atate-tranaition 


(defrule  get-ending-atate 
(declare  (aalience  100)) 

Tx  <-  (get-ending-atate) 
(beginning-atate  TBS) 

(pronpt  TPI  TR1  TT1ME  TSCH) 

(achetaa  TSCH 

(inatance-of  faa-uaer-rcaponaea) 
(initial-atate  TIS)) 

■> 

(retract  Tx) 

(printout  t  t  "Ending  State:  ") 


(bind  7ES  (read)) 

(if  (end  (syobolp  TES)  (not  (null  7ES)))  theo 
(if  (valid-Ada-identifier  TES)  then 
(aaaert  (ending-atete  TES) 
(get-actioos)) 


elae 

(printout  t  t  "Error  -  Invalid  Ade  ideotifier  entered.") 
(aaaert  (get-ending-state) )) 

elae 

(printout  t  t  "Eoding  etate  must  be  e  symbol.") 

(aaaert  (get-ending-atete)))) 


rjmir.t  the  ecticr.0  associated  vith  the  tranaition 

Tie  user  id  at  specify  the  Ada  package  that  contains  a  routine  to  perform  the 
desired  action,  aod  the  oame  of  the  routine.  The  specification  ie  in  the 
fora  of  e  LISP  list, 

e.g. ,  (prepere_for_ leuoch  ignite. eogines) 


(defrule  get-actions 

(declere  (selieoce  100)) 

Ts  <-  (get-actions) 

(ending-state  T) 

■> 

(retrect  Tt) 

(printout  t  t  "Action:  ") 

(bind  TACTION  (read)) 

(if  #L( lisp: listp  TACTION)  theo 

(if  (valid-list-of-Ada-identifiers  TACTION)  theo 
(bind  Tseq-action  (seq*$  Tection)) 

(assert  (ection  Tseq-ection)) 
else 

(priotout  t  t  "Invalid  Ada  ideotifier  entered  for  a  coapooent  of  ACTION.") 
(essert  (get-actions))) 

else 

(printout  t  t  "Actions  must  be  entered  es  a  list  io  the  following  fora:  ") 
(printout  t  t  "  (<aetion_peckege>  <ection_routine>)  or  NIL") 

(essert  (get-actioos)))) 


Updates  the  state-trsnsit ion  information  vith  the  latest  state-treosi tioo 
thet  has  been  provided  by  the  user. 


(defrule  update-state-trensi tions 
(prompt  TPI  TRI  7TIME  Tsch) 

Ta  <-  (beginning-state  TBS) 

Tb  <-  (events  T EVENTS) 

Tc  <-  (ending-state  TES) 

Td  <-  (action  TACTION) 

( ->  (biod  Tlist-events  (list*$  TEVENTS)) 
(bind  T list-action  (liet*$  TACTION))) 
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(cate 

(Tx  <-  (initial-sequence) 

■  > 

(retract  Tx) 

(bind  TSEQST  (seq*$  (list  (liat  TBS  TEventa  TES  TACTION)))) 
(ataert  (schema  Tach  (atate-tranaitiona  TSEQST)) )) 

((schema  Tech  (atate-tranaitiona  TS)) 

-> 

(bind  TST  (liat  TBS  Tlist-eventa  TES  Tliat-action)) 

(bind  Tliatr  (liat*$  TR ) ) 

(bind  Taeqat  (aeq*S  (redundancy-elimination  Tat  Tliatr))) 
(modify  (schema  Tech  (atate-tranaitiona  Taeqat))))) 

(retract  Ta  Tb  Tc  Td) 

(aaaert  (get-beginning-state))) 


Verifies  that  the  tame  stimuli  applied  to  the  same  atate  does  not  reault  in 
2  different  tranaitiona. 


(defrule  check-for-nondeterminitm 

Tx  <-  (nd-check  TPI  Til  TTIHE) 

(schema  T 

(inatance-of  ftm-uaer-responaea) 

(part-id  TFI) 

(revision-id  TR1) 

(timeatamp  TTIKE) 

(atate-tranaitiona  TST)) 

-> 

(retract  Tx) 

(if  (eignal-nondeterminiem-error  (liat*S  TST))  then 

(printout  t  t  "***  Invalid  State-Tranaition  Data  Entered  ***") 
(printout  t  t  *****  Unable  to  continue  processing  for  this  part  ***") 
(assert  (error  input-data)) 
else  (printout  t  t  "Data  passed  nd  check") 

(assert  (extract-sea  TPI  TH  TTIHE)))) 


Extracts  states,  events,  and  actions  from  an  embedded  sequence  and  forms  a 
sequence  for  each  of  the  three.  This  data  is  used  when  generating  the  Ada 
code  for  the  component  under  construction.  It  is  simpler  to  prepare  the 
information  ahead  of  time. 


(defrule  extract-states-events 

Tx  <-  (extract-sea  TPI  TBI  TTIHE) 

(schema  Tech 

(instance-of  fsm-usar-responses) 
(part-id  TPI) 


(revision-id  TRI) 

(tunas tamp  TTIHE) 

(state-transitions  ?R) 

(stataa  Tatatas)) 

(assart  (chack-for-unraacbabla  TPI  TRI  TTIHE)) 

(ratract  Tx) 

(bind  Tlistr  (list*$  TR)) 

(bind  Taaqstatas  (saq$  'make-states  Tliatr  (listS  Tatatas)))) 
(bind  Ttaqavants  (saqS  (make-events  Tliatr  nil))) 

(bind  Taaqactiona  (aeq$  (make-actions  Tliatr  oil))) 

(bind  Taeqbatataa  (aaqS  (make-bs tatas  Tliatr  nil))) 

(assart  (action-packagas  Taaqactiona)) 

(assart  (baginning-statas  Taeqbatataa)) 

(assart  (avanta  Taaqavants)) 

(modify 

(schema  Tacb 

(stataa  Taaqstatas)))) 


Chacks  atata-traoaitiona  for  unraachabla  atataa 


(defrula  chack-unreachabla-atata 

Tx  <-  (chack-for-unraachabla  TPI  TRI  TTIHE) 

(bagiooiog-atataa  TBSTATES) 

(acbaaa  T 

(ioataoca-of  fsm-usar-rasponses) 

(part-id  TPI) 

(raviaion-id  TRI) 

(tiaaataop  TTIHE) 

( ioitial-atata  TIS) 

(atata-traoaitiona  TR)) 

■> 

(ratract  Tx) 

(bind  Tlist-batataa  (list*$  Tbatataa)) 

(bind  Tliatr  (list*$  TR)) 

(bind  Too-uoraacbablaa  (aignal-uoraacbabla-stata  TIS  Tlist-batataa  Tliatr)) 
(if  Tno-unraachablaa  than 

(printout  t  t  "Data  paaaad  chack  for  unraachabla  atataa.") 

(aaaart  (build-part  TPI  TRI  TTIHE)) 

alaa 

(printout  t  t  *****  Invalid  Stata-Traoaitioo  Data  Entarad  ***") 
(printout  t  t  “Unraachabla  atata  datactad  in  fan:  n  Tno-unraachablaa) 
(aaaart  (arror  input-data)))) 


Genaratas  tha  FSH  component  specified  by  tha  uaar 


(dafrula  build-fsm 
(not  (arror  T)) 

Ta  <-  (build-part  TPI  TRI  TTIHE) 


Tx  <-  (action-package*  Taction*) 

Ty  <-  (event*  Teventa) 

Tz  <-  ( beginning-atates  Tbatatea) 

(achema  Tach 

(inatance-of  fam-uaer-reaponae* ) 

(part-id  TP1) 

(reviaion-id  TRI) 

(timestamp  TTIME) 

( initial-atate  TIS) 

(file-name  Tfile-name) 

(component -name  TON) 

(atatea  TSTATES) 

(atate-tranaitiona  TST)) 

(achema  Tb 

(inatance-of  part-to-build) 

(part-id  TPI) 

(reviaion-id  TRI) 

(to-build-from  Tfrom)) 

(printout  t  t  "Constructing  component  "  TCN) 

(bind  Toutput  #L(open  Tfile-name  direction  :output 

:if-eziata  :nev-varaion 
:if-does-not-exiat  :create)) 

( wri te-f sm-header  Toutput  (liatS  Tactions)  Ten  ( list 9  Tatatea)  (list?  Teventa)  Tia) 

(bind  Tinput  #L(open  Tfrom  :direction  : input)) 

(read-loop  Tinput  Toutput) 

(write-aelection-code  Toutput  (list$  Tbatatea)  ( liet*$  TST)) 

(princ  "  end  Signal;"  Toutput) 

(terpri  Toutput) 

(terpri  Toutput) 

(princ  "end  "  Toutput) 

(princ  Ten  Toutput) 

(princ  "j"  Toutput) 

(terpri  Toutput) 

(close  Toutput) 

(retract  Tx  Ty  Tz  Ta  Tb)) 


This  component  contains  the  LISP  utilities.  Many  of  these  routines  are  quite 
general,  and  can  be  used  by  other  functions  within  the  AMPEE  system. 


Extern*  1  routine  to  clear  the  acreen  -  DEC  ex  ten*  ion  to  Conon  Li»p 


(define-ex tern* 1-routine 

(eraae-pege  :im*ge-name  "acrahr" 

:entry-point  "lib$er**e_p*ge" 
:check-status-return  t) 

(line  :liap-type  integer 
:v*x-type  :word) 

(col  : lisp-type  integer 
:vax-type  :word)) 


Hane:  read-loop 

Alphe  A  beta  sust  be  bound  to  *treaa>  name* 

Pjroceaaing:  This  routine  reeda  from  atreem  'alphe'  end  writs*  to  stress 
'bets'.  The  input  stream  ia  closed  efter  end-of-file  is  reecbed,  but  it 
is  left  to  the  calling  rountine  to  close  ths  output  streen. 


(defun  reed- loop  (alpha  bete)  ' 

(cond  ((write-line  (read-line  alpha  nil)  bete)  (reed-loop  elpba  bate)) 
(t  (close  elphe)))) 


Name:  write-event-or-list 

Writs*  disjunction  of  event  elements  in  'lists'  to  'out put -stream' 
Example:  liste  :■  (a  b  c) 

,  output:  (event  e)  or  (event  b)  or  (evsnt  c) 


(defun  write-event-or-list  (output-streem  liste  line-lengtb) 

(cond  ((>  (length  liste)  0) 

(setq  line-lengtb  (♦  line-length 

(♦  14  (lsngtb  (string  (car  liste)))))) 
(cond  ((>  line-length  119) 

(terpri  output-stress) 

(princ  "  M  output-stress) 

(setq  line-length  6)) 

(T  nil))) 


(T  nil)) 


(cond  ((>  (length  liste)  1)  (princ  “(event  *  "  output-stress) 

(princ  (cer  liste)  output-strees) 
(princ  ")  or  M  output-stress) 
(write-event-or-list  output-strsaa 
(cdr  liste) 
line-lengtb)) 

(t  (princ  "(event  “  "  output-stress) 

(princ  (car  liste)  output-stress) 

(princ  ")"  output-stress)))) 


;  Wane:  write-alteration-liet  „  . 

;  Write*  disjunction  of  element*  in  'liite  to  output-atream  with 
;  the  alteration  symbol  instead  of  'or' 

;  Example:  liate  :•  (a  b  c) 

;  output:  l  I  b  I  c  _ _ 


(defun  write-alteration-list  (output-stream  liate  line-length) 

(cond  ((>  (length  liate)  0) 

(aetq  line-length  (♦  line-length  ...... 

(♦  3  (length  (string  (car  liate)))))) 


(cond  ((>  line-length  119) 

(terpri  output-atream) 

(princ  *  "  output-atream) 

(aetq  line-length  6)) 

(T  nil))) 


(T  nil)) 

(cond  ((>  (length  liate)  1)  (princ  (car  liate)  output-atream) 

(princ  "  I  "  output-atream) 
(write-alteration-liat  output-atream 
(cdr  liate) 
line-length)) 

(t  (princ  (car  liate)  output-atream)))) 


Name:  write-conna-liat 

Writea  'coma  liat'  of  elementa  in  LISTE  to  OUTPUT-STREAM 
Example:  LISTE  :■  (a  b  c) 

OUTPUT:  a,  b,  e 


(defun  write-comma-liat  (output-atream  liate  line-length) 

;  firat  decide  if  output  ahould  be  written  on  current  line  or  if  a 


linefeed  ia  needed. 

(coed  ((>  (length  liate)  0) 

(aetq  line-length  (♦ 


line-length  ...... 

(♦  2  (leneth  (string  (car  liate)))))) 


(cond  ((>  line-length  119) 

(terpri  output-streem) 

(princ  M  "  output-atream) 

(aetq  line-length  6)) 

(T  nil))) 


(T  nil)) 


(cond  ((>  (length  liate)  1)  (princ  (car  liate)  output-atream) 

(princ  ",  "  output-atream) 
(write-comma-liat  output-atream 
(cdr  liate) 
line-length)) 


(t  (princ  (car  liate)  output-atream)))) 
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forms  &  list  of  all  of  the  states  found  in  the  input  data.  The  list 
used  to  declare  an  enumeration  data  type  in  the  Ada  component  being 
generated. 

SEQ  is  in  the  form:  ((BS  (events)  ES  (action))  ...) 

STATES  is  if  the  form:  (S!  S2  ...  Sn) 


(defun  make-state6  (seq  states) 

(cond  ((>  (length  seq)  C) 

(setq  states  (union 

(remove-duplicates  (list  (caar  seq)  (caddar  seq))) 
states)) 

(make-states  (cdr  seq)  states)) 

(t  states))) 


Maine:  make-batatas 

Extracts  only  the  beginning  states  from  the  embedded  lists  of 
state-transitions;  SEQ  is  of  the  same  form  as  above 


(defun  make-batates  (seq  bstates) 

(cond  ((>  (length  aeq)  0) 

( tetq  bstates  (union  (list  (caar  aeq))  bstates)) 
(make-bstates  (cdr  aeq)  bstates)) 

(T  bstates))) 


Name:  make-events 

Extracts  all  of  the  events  from  the  embedded  lists  of  atate-tranaitiooa 
(i.e. ,  it  forms  a  list  of  all  events  found  in  the  input  data  provided  by 
the  user). 

SEQ  ia  of  the  same  form  as  above 
EVENTS  is  in  the  form:  (El  E2  ...  En) 


(defun  make-events  (aeq  events) 

(cond  ((null  events)  (setq  events  (cadar  aeq)) 

(make-events  (cdr  aeq)  events)) 

((>  (length  aeq)  0)  (setq  events  (union  (cadar  aeq)  events)) 
(make-events  (cdr  seq)  events)) 

(t  events))) 


Name:  make-actions 

Extracts  all  of  the  action  packages  from  the  embedded  lists  of  state-transi¬ 
tions;  if  the  action  ia  NIL,  it  ia  not  added  to  list  of  actions.  The 
actions  are  HITHed  into  the  Ada  component  that  ia  to  be  generated. 

SEQ  is  the  same  form  aa  above. 

ACTIONS  is  of  the  form:  (Al  A2  ...  An) 


(defun  make-actions  (aeq  actions) 

(cond  ((and  (null  (car  (last  (car  aeq))))  (>  (length  aeq)  0)) 
(make-actions  (cdr  seq)  actions)) 


a 


I 


V 


Vi 

•*> 


3 

i 


►V 


S: 

* 


■c. 


■  _•« '  v. 


--  .*  ■.*' 


154 


(Coull  action*)  (aetq  action*  (li»t  (e««r  (lot  (car  aeq))))) 

(aaka-cctiona  (cdr  acq)  action*)) 

((>  (length  acq)  0)  (actq  cction*  (unioo  (liat  (cccr  (lcat  (car  ccq))))  aCtitai)) 
(aaka-cctiona  (cdr  ccq)  cctiona)) 

(T  action*))) 


;  lac:  vrite-f aa-hecdcr 

;  Write*  the  ioiticl  portion  of  Ada  code  for  the  fea  pert 
;  OUTPUT-STREAM:  Name  of  output  atreaa 

;  WITH -ACTION :  Liat  of  peckegea  to  be  WITHed  ioto  the  Ad*  coapooeot  that  ia 
;  uoder  cooat  ruction.  It  ia  of  the  form  (A1  A2  ...  As) 

,  CM •  The  naae  of  the  coapooaot  under  cooatructioo.  Thia  auat  be  a  valid  Ade 
;  identifier 

;  IXATCS:  Liat  of  atetea  uaed  in  declaration  of  eouacretion  date  type 
;  .  repreaentiog  *11  poaaibl*  atetea. 

;  EVENTS:  Liat  of  event*  uaed  io  the  decleretioo  of  enuaeretion  data  type 
;  repreaeoting  ell  poaaible  event*. 

;  IS:  Ieitiel  atete 

(defuo  vrite-f aa-hccder  (output-atreaa  vith-ectiooa  co  atetea  eveot*  ie) 

(coad  ((>  ( laogth  WITH -ACTIONS)  1) 

(prioc  “with  "  output-atrern) 

( vri  tc-ceaie-liat  O'jTPIi  T-SIREAM  WITH -ACTIONS  5) 

(princ  output-atreea)) 

( (eod  (-  ( leogth  WITH-ACTlONS)  1) 

(not  (equelp  (car  WITH-ACTIONS)  oil))) 

(prioc  “with  M  OUTPUT-STREAM) 

(prioc  (car  WITH-ACTIONS)  OUTPUT-STREAM) 

(prioc  output-atreaa)) 

(T  oil)) 

(terpri  output-etreaa) 

(price  "package  "  OUTPUT-STREAM) 

(prioc  CM  OUTPUT-STREAM) 

(prioc  M  ia"  OUTPUT-STREAM) 

(terpri  OUTPUT-STEEAM) 

(prioc  *  type  State*  ia  ("  OUTPUT-STEEAM) 

(vritc-coac-liat  OUTPUT-STEEAM  STATES  IS) 

(priee  ");"  OUTPUT-STEEAM) 

(terpri  OUTPUT-STEEAM) 

(prioc  M  type  Stiauli  i*  ("  OUTPUT-STEEAM) 

(vrite-coac-liat  OUTPUT-STEEAM  EVENTS  19) 

(prioc  ");"  OUTPUT-STEEAM) 

(terpri  OUTPUT-STEEAM) 

(prioc  "  function  Curreot.Btet*  returo  State*;"  OUTPUT-STEEAM) 

(terpri  OUTPUT-STEEAM) 

(princ  “  procedure  Sigoel  (Eveot  :  io  Stimuli);**  OUTPUT-STEEAM) 

(terpri  OUTPUT-STEEAM) 

(prioc  **  lovelid.Stiauli  :  EXCEPTION;"  OUTPUT-STEEAM) 

(terpri  OUTPUT-STREAM) 
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(princ  "end  "  OUTPUT-STREAM) 

(princ  CN  OUTPUT-STREAM) 

(princ  V'  OUTPUT-STREAM) 

(terpri  OUTPUT-STREAM) 

(terpri  OUTPUT-STREAM) 

(princ  "package  body  "  OUTPUT-STREAM) 

(princ  CM  OUTPUT-STREAM' 

(princ  "  i*  "  OUTPUT-STREAM; 

(terpri  OUTPUT-STREAM) 

(princ  M  Preaent_State  :  Stetea  ’  OUTPUT-STREAM) 
(princ  IS  OUTPUT-STREAM) 

(princ  OUTPUT-STREAM) 

(terpri  OUTPUT-STREAM)) 


;  Naae:  write-aelection-code  , 

;  Determine*  whether  the  fan  component  ehould  be  written  with  e 
;  'ceae'  atateoent  or  with  en  'if-then-elae ';  the  criteria  ia  the 
;  number  of  atetea  that  were  apecified  (i.e. ,  the  length  of  STATES ). 

(defun  write-aelection-code  (output-atreaa  atetea  atete-trenaitiona) 

(eond  ((>  (length  atetea)  2) 

(wri te-atate-ceae  output-atreem  atatea  atete-trenaitiona)) 

((and  ( <-  (length  atatea)  2)  (>  (length  atetea)  0)) 

(wri te-atate-if-elaif  output-atreem  atetea  atete-trenaitiona)) 

(T  'ERROR))) 


Naae:  write-atate-caae 

Proceaaea  the  uae  of  e  'caae'  atetement  for  the  major  ateta  selection 
criteria  (baaed  on  total  number  of  atetea) 

OUTPUT- STREAM:  the  name  of  the  output  atream 
STATES:  A  liat  of  all  'beginning'  atetea 

STATE-TRANSITIONS:  A  liat  of  ell  atete-trenaitiona  entered  by  the  uaer 


(defun  write-atete-ceae  (output-atreem  atatea  atete-trenaitiona) 
(princ  "  caae  Preaent_State  ia  "  output-atream) 

(terpri  output-atreaa) 

( loop 

(aetq  atate  (car  atatea)) 

(princ  "  when  "  output-atreaa) 

(princ  atete  output-atreaa) 

(princ  "  •>"  output-atreem) 

(terpri  output-atreaa) 

(aetq  atate-i-trenaitiona 

(make-atate-tranaitiona  atete  '()  atete-trenaitiona)) 


(process-transition*  nutput-straam  stats-i-traositions) 

(setq  states  (edr  statas)) 

(cond  ((“  (length  states)  0)  (return)) 

(T  oil))) 

(terpri  output-stream) 

(terpri  output-stream) 

(princ  **  vheo  others  ■>  raise  iovelid_stimuli;"  output-stresm) 

(terpri  output-stream) 

(princ  "  aod  case;"  output- stream) 

(terpri  output-stream)) 


;  Name:  vrita-ststa-if-elsif  . 

;  Processes  tha  use  of  so  'if-then-ejse'  statement  fnr  the  'state' 

;  selection  criteria  (besed  on  the  total  number  of  stetes) 

(dafun  write-stete-if-elsif  (nut put-stream  stetes  stete-trensitioos) 
(princ  "  if  "  mit put-stream) 

;;;  loop 

(loop 

(setq  state  (car  states)) 

(princ  "present_*tete  *  M  output-streem) 

(prioc  state  output-stream) 

(princ  "  then"  nutput-streem) 

(terpri  output-stream) 

(setq  stata-i-traositions 

(make-stete-t renditions  stste  '()  stete-trensitions)) 

(procass-transit ions  output-stream  stete-i-trensitions) 

(setq  states  (edr  stste*)) 

(cond  ((•  (length  statas)  0)  (returo)) 

(T  (terpri  output-stream) 

(princ  "  alsif  "  output-straem)))) 

; ; ;  END  LOOP 

(princ  "  alsa  M  output-stream) 

(tarpri  output-stream) 

(princ  H  raise  Xnvalid.Stimuli;"  nutput-straam) 

(terpri  output-streem) 

(princ  "  end  if;"  output-streem) 

(tarpri  output-straam)) 


;  Nam*:  meke-statc-treositioos 


157 


;  Extract*  one  state-transition  aet  from  the  entire  aet  of  atate-tranaition*. 

;  For  a  given  atate,  this  routine  make*  a  liat  whose  car  ia  that  atate  and 
;  whose  cdr  is  a  liat  of  stimuli,  transitions,  and  associated  actions  that 
;  originate  at  'STATE'. 

;  STATE;  A  single  initial  state;  all  tranisitions  that  begin  with  this  atate 
;  will  be  found 

;  ONE-STATE:  The  aet  of  transitions  associated  with  a  particular  state;  it  is 
;  in  the  following  form: 

;  (STATE  (((event_listl)  ESI  (actionsl))  ((event_list2)  ES2  (action*2)) 

;  When  passed  in,  this  variable  should  be  a  null  list;  it  it  then  initialized 
;  to  a  list  containing  the  value  of  'STATE'. 

;  STATE-TRANSITIONS;  In  the  form  shown  below: 

;  ((sO  (event_ listO)  eaO  *0))  (si  (event_ liatl )  eal  al)  ...) 

(defun  make-atate-tranai tions  (state  one-state  atate-transitions) 

(cond  ((and  (>  (length  state-transitions)  0) 

(equal  (caar  state-transitions)  state)) 

(setq  one-state  (append  one-state  (list  (cdar  atate-tranaition*)))) 
(mske-state-tranaitions  state  one-atate  (cdr  state-transitions))) 

((>  (length  state-transitions)  0) 

(make-state-tranaition*  atate  one-atate  (cdr  state-transition*)) ) 


(T  (append  (list  state)  one-atate)))) 


;  Name:  process-transitions 

(defun  process-trsnaitions  (output-stream  atate-i-transitiona) 

(cond  ((>  (length  (cdr  state-i-transitions))  2) 

.  (write-event-case  output-stream  *tate-i-tran*itions)) 

((>  (length  (cdr  st*te-i-tran*ition*))  0) 

(write-event-if-elaif  output-stream  state-i-transitiona) ) 

(T  'ERROR))) 


Name:  write-event -case 

Processes  the  use  of  a  'case'  statement  for  the  events;  i.e.,  if  there  are 
multiple  conditions  that  cause  transition,  the  total  number  will  determine 
whether  they  will  be  handled  with  a  'case'  statement  or  an  'if-then-elae ' 
OUTPUT-STREAM:  The  name  of  the  output-stream 

STATE- I -TRANSITIONS:  The  set  of  transitions  associated  with  a  particular 
state;  this  is  obtained  via  the  'HAKE-STATE- TRANS  1 TIONS'  function 
Internal  variables: 

STATE:  A  beginning  atate  (for  a  state  transition) 

TRANSITIONS:  The  set  of  all  transitions  (stimuli,  anding  state,  and 
associated  actions)  associated  with  'STATE' 

CASE-1:  One  particular  transition  associated  with  'STATE'  (it  consists  of 
the  following:  (( event,  list )  ending_atate  actions) 
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(princ  *'  then"  output-stream) 

(terpri  output-stream) 

(f sm-actinn-update  output-stream  state  case-i) 

(aetq  transitions  (cdr  transition*)) 

(cond  ((«  (length  transition*)  0) 

(princ  "  else"  nutput-atream) 

(terpri  output-stream) 

(princ  "  raise  Invalid_St imul i ; "  output-stream) 

(terpri  output-stream) 

(return)) 

(T  (princ  "  elsif  "  output-stream)))) 

(princ  "  end  if;"  output-stream) 

(terpri  output-stream)) 


;  Name:  fsm-act inn-update 

;  Processing:  Writes  the  Ada  code  to  (1)  call  the  routine*  that  perform  the 
;  actions  associated  with  the  transition,  and  (2)  update  the  currant  state. 

;  Nnte  that  the  current  state  is  not  updated  if  the  stimuli  doe*  not  result  in 
;  an  actual  change  in  state. 

(defun  f sm-actinn-update  (output-stream  state  caac-i) 

(aetq  action-i  (caddr  case-i)) 

(cond  ((not  (null  actinn-i)) 

(prine  "  M  output-stream) 

(princ  (string-append  (car  action-i)  ". M  (cadr  action-i))  output-stream) 
(princ  output-stream) 

(terpri  output-stream)) 

(T  nil)) 

(cond  ((equalp  state  (cadr  case-i))  nil) 

(T  (princ  "  Pre*ent_Bt*te  :»  **  output-stream) 

(princ  (cadr  case-i)  outpot-strean) 

(princ  nutput-atre an) 

(terpri  output-strean)) ) 

(cond  ((and  (null  actinn-i)  (equnlp  state  (cadr  case-i))) 

(princ  "  NULL:"  output-stress-) 

(terpri  output-stress.)) 

(T  nil))) 


t-'ar.e :  sip.no  l-nondeten.ini  sc- error 

Processing:  This  routine  determine*  If  there  exists  two  sets  nf  transitions 
m  cl  tint  tie  l.epir.i  irp  state  for  boll-  art-  the  safe,  tin  ending,  Mtte  for 
ti’  c  it  transition  i*-  different,  but  tlij  l-rvt  ft  ltast  nne  stiinli  in  ct<n  on; 
i.e. ,  it  looks  for  situations  where  the  saue  atisuli  at  a  Liven  state 
results  in  transitions  to  2  different  states. 

ST  is  the  collection  nf  state-transition*  input  by  the  user 
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(defun  signal-nondetciuinism-arror  (ST) 
(setq  error  nil) 

(•etq  state  (eaar  at)) 

(aatq  anding-atata  (caddar  at)) 

(aetq  avent-aaq  (cedar  at)) 

(aetq  action  (ear  (cddar  at))) 

(aatq  reuse-at  (cdr  at)) 

(aetq  nav-st  '()) 

;LOOP 
( loop 
(eond 


if  the  beginning  stataa  and  ending  statas  are  the  saaa 

than  procaed  by  getting  the  next  state-transition  (don't  Dead  to 
axamina  the  stimuli  for  tbia  condition) 


((and  (>  (length  reusa-at)  0) 

(equal  atata  (caar  rauaa-st)) 

(equal  ending-atata  (caddar  rause-st))) 

(cond 

((list-equal  action  (car  (edddar  rausa-st))) 
(aatq  rause-at  (cdr  reusa-st))) 

(T  (aatq  arror  T) 

(return)))) 


if  the  beginning  states  are  the  same,  but  tba  ending  stataa  ara 
different,  and  the  tvo  transitions  have  stimuli  in  come on 
then  signal  an  error 


((and  (>  (length  reuae-at)  0) 

(equal  state  (caar  rcuae-st)) 

(not  (equal  ending-state  (caddar  reuse-st))) 

(not  (null  (intersection  avant-aeq  (cedar  rause-st))))) 
(aetq  error  T) 

(return)) 


if  there  are  no  more  state-transitions  to  axamina 
than  exit  the  loop 


((■  (length  reusa-at)  0) 
(return)) 


otherwise 

add  tha  state  transition  just  looked  at  to  nav-st 
proceed  with  the  examination  of  the  next  state-transition  in  tba 
list  rause-st 


(T  (aetq  nev-st  (append  (list  (ear  rausa-st))  nev-st)) 
(satq  rausa-st  (cdr  reusa-st))))) 

;  END  LOOP 
(cond 

((equal  arror  T)  arror) 


((>  ( length  st)  1) 


(setq  st  new-st) 

(signal-nondeterminism-error  st)) 


(1  NIL))) 


;  Name:  redundancy-elimination 

;  Processing:  As  the  user  enters  a  atate-tranaition,  tbia  routine  eliminates 
;  the  following  redundancy: 

;  if  (bsO  ■  bsl )  and  (esO  ■  esl)  and  (actionaO  -  actional) 

;  then  event-seq  *  (event-seqO  ♦  event-aeql) 

(defun  redundancy-elimination  (one-state-transition  aeq-of-atate-tranaitiona) 
(setq  beginning-state  (car  one-state-traneition)) 
faetq  event-seq  (cadr  one-atate-tranaition)) 

(setq  ending-state  (caddr  one-atate-tranaition)) 

(aetq  action  (car  (edddr  one-atate-tranaition))) 

(setq  nev-6t  '()) 

;L00P 
( loop 
(cond 

((and  (>  (length  aeq-of-atate-tranaitiona)  0) 

(equal  beginning-state  (caar  aeq-of-atate-tranaitiona)) 

(equal  ending-state  (caddar  aeq-of-atate-tranaitiona))) 

(aetq  event-seq 

(remove-duplicates 

(append  event-aeq  (cadar  aeq-of-atate-tranaitiona)))) 

(setq  aeq-of-atate-tranaitiona  (cdr  aeq-of-atate-tranaitiona))) 

((-  (length  aeq-of-state-tranaitiona)  0) 

(return  (append 

(list  (list  beginning-state  event-aeq  ending-state  action)) 
new-st))) 

(T  (setq  new-at  (append  (list  (ear  aeq-of-atate-tranaitiona))  nev-st)) 
(aetq  seq-of-atate-tranaitiona  (cdr  aeq-of-atate-tranaitiona)))))) 

;END  LOOP 


Name:  list-equal 

Processing:  Civen  two  lists,  determines  if  they  are  equal.  Test-elements  is 
called  to  check,  the  lists  element  by  element. 


(defun  list-equal  (A  B) 

( cond 

((not  (■  (length  A)  (length  B)))  NIL) 
(T  (teat-elements  A  B)))) 
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(d*fun  test-elements  (A  B) 

(cnnd 

((and  (>  (length  A)  0) 

(equal  (car  A)  (car  B))> 

(teat -element a  (edr  A)  (edr  B) } ) 

((-  (length  A)  0)  T) 

(T  NIL)}) 


Naae:  aignel-unrcachable-atete 

Output:  returna  the  tmreecheble  atate  if  one  ia  found,  otherwise  returns  T 


(defun  eignal-unreecheble-atete  (initial-stete  batetes  state-transitions) 
(setq  error  nil) 

(setq  ba  (car  batatea)) 

(aetq  reuae-at  atete-tranaitinna) . 

;  LOOP 
( loop 

(aetq  aingle-at  (cer  reuae-at)) 

(setq  reuae-at  (edr  reuae-at)) 

(cnnd 


if  beginning  state  ia  the  initial  state  then  don't  look  for 
transition*  into  it 


((equslp  bs  initiel-stete) 
(return  nil)) 


if  the  beginning  state  *  tbe  ending  state  of  seae  other  atate 
transition,  and  tbe  beginning  state  of  that  transition  ia  not 
same  aa  ba,  then  there  ia  a  transition  into  ba  and  it  ia  not 
unreachable 


((end  (equalp  (ceddr  aingle-at)  ba) 

(not  (cquetp  (cer  aingle-at)  ba))) 
(return  nil)) 


if  all  atete-trenaitions  have  been  checked,  but  no  trenaitiooa 
have  been  found  into  tbe  state,  than  it  ia  unreachable 


((eaual  (length  reuae-at)  0) 
(aetq  error  T) 

(return  error)) 

(T  nil))) 


;END  LOOP 


(error  be) 


((>  (length  betetee)  1) 

(eignel-unreechable-etete  initiel-etete 

(cdr  betetee) 
etete-traneitionc)) 

(T  T) ) ) 


;  Name:  valid-list-of-Ada-identifiers 

;  Inputs:  liet  of  identifiere  to  be  checked  for  validity  ae  Ada  identifiere 
;  Froceeeing:  Each  element  of  the  liet  ie  teeted  for  validity  ae  a  valid 
;  Ada  identifier 

;  Outpute:  T  if  each  element  of  the  liet  ie  a  valid  Ada  identifier; 

;  Nil  otherwise 

(defun  valid-liet-of-Ada-ident if iere  ( liet-of-ident ifiere) 

(cood  ((and  (>  (length  liet-of-ident ifiere)  0) 

(valid-Ada-identifier  (car  liet-of-ident ifiere) )) 

( valid-liet-of-Ada-ident if iere  (cdr  liet-of-ideotif iere))) 

((•  (length  liet-of-ident ifiere)  0)  T) 

(T  nil))) 


;  Name:  valid-Ada-identifier 

;  lopute:  An  eymbol  that  ie  to  be  teeted  ae  a  valid  Ada  ideotifier 
;  Froceeeing:  The  eymbol  ie  firet  'exploded'  to  form  a  liet  of  each  of  the 
;  conetitueot  elemente  of  the  eymbol,  e.g. ,  compute_oortli_ velocity  becomes 
;  ("c"  "o"  "m"  "p"  "u"  "t"  "e .  "o"  "o"  "r"  "t"  "h .  "v"  "e"  "1"  Mo“ 

•*C*  MjH  MyM), 

;  After  explodiog  the  eymbol,  varioue  teeta  are  applied  to  determine  if  it 
;  conforms  to  the  requirements  for  a  valid  Ada  identifier. 

;  Outpute:  T  if  the  symbol  repreeeote  a  valid  Ada  ideotifier 
;  NIL  otherwise 

(dsfun  valid-Ada-identifier  (identifier) 

(sstq  characters  '("A"  "B"  "CM  "D"  ME"  "F"  "C"  ••H"  “1“  "JH  nt"  “L”  “KM  "N" 
••0"  "F"  •■Q"  "R"  "S"  "TH  "U"  "V"  "W"  "X"  "T"  "Z")) 

(sctq  numbers  '("O"  Ml"  M2M  "3"  "4M  “5"  M6"  “7“  “6"  “9")) 

(setq  list-identifier  (explode  identifier)) 

(cond  ((member  (car  list-identifier)  characters  :teet  #'equslp) 

(psree-ideotifier  (cdr  list-ideotifier)  characters  numbers)) 

(T  NIL))) 
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Neme:  perse-identifier 
Inputs: 

list-identifier:  e  list  made  up  of  the  constituent  elements  of  the 
identifier  (ell  elements  must  be  in  the  seme  order  es  in  the 
original  symbol 

cherecters:  e  list  consisting  of  ell  slphe  chereeters  (order  is  not 
important) 

numbers:  e  list  consisting  of  the  numbera  from  0  to  9  (order  is  not 
importent) 

(defun  parse-identifier  (list-identifier  eheraeters  numbers) 

(cond  ((null  list-identifier)  T) 


((member  (eer  list-identifier)  (union  cherectera  numbers) 

:test  d'equelp) 

(perse-identifier  (edr  list-identifier)  eheraeters  numbera)) 


((equelp  (ear  list-identifier)  M_M) 

(cond  ((member  (e*dr  list-identifier) 

(union  characters  numbers)  :test  f'equelp) 
(perse-identifier  (eddr  list-identifier) 
characters  numbera)) 


(T  nil))) 


((equelp  (cer  list-identifier)  M.M) 

(cond  ((member  (cedr  list-identifier)  cherecters  :test  d'equelp) 
(perse-identifier  (eddr  list-identifier) 
cherecters  numbers)) 


(T  nil))) 


(I  nil))) 


N«me:  explode 

Inputs:  A  symbol  thet  is  to  be  trensformed  into  e  list  of  its  consituent 
elements 

Outputs:  A  list  of  the  elements  (in  the  same  order  as  they  eppear  in  the 
identifier)  thet  comprise  the  identifier.  Duplicetea  are  not  resMved  aa 
they  are  aignificent  to  proper  parsing. 


(defun  explode  (identifier) 

(cond  ((>  (length  (string  identifier))  1) 

(make-identifier-list  (string  identifier) 

'() 

(length  (string  identifier)))) 

( ( -  (length  (string  identifier))  1) 

(list  (string  identifier))) 


(T  HIL))) 


Name:  make-ident ifier-list 
loputc : 

string-identifier:  the  string  representation  of  the  original  identifier 
lilt-identifier:  the  lilt  representation  of  string-identifier 
index:  used  to  index  elements  in  the  string  in  order  to  break  them  out 
separately  in  the  list 


(defun  mske-identifier-list  (string-identifier  liat-idsnt ifisr  indea) 
(setq  list-identifier 

(append  (list  (subseq  string-identifier  (-  index  1)  indea)) 
list-identifier)) 

(cond  ((>  index  1) 

(setq  index  (-  index  1)) 

(make-identifier-list  string-ident iMar 
list-identif isr 
index)) 

(T  list-identifier))) 


;  Name:  main-menu 

;  Processing:  This  routine  clears  the  screen,  established  menu  entries  for 
;  the  AMPLE  System  main  menu,  and  calls  routines  to  display  that  menu.  The 
;  users  response  is  processed.  If  an  unimplemented  feature  is  selected,  the 
;  routine  is  called  again. 

;  Output:  The  menu  is  displayed 

(defun  main-menu  () 

(call-out  erase-page  1  I) 

(setq  path  '( lAda  Missile  Parts  Engineering  Expert  Systeml)) 

(setq  menu.list  (add_nuahers  '((iFarts  Catalog!) 

( IParta  Identification!) 

( I  Component  Construction!)))) 

(setq  answer  (menu_read  path  menu_list  nil  nil)) 

(cond  ((equslp  (car  answer)  'IParta  Catalog!) 

(terpri) 

(pprint  "The  Parts  Catalog  facility  is  not  yet  available.") 

(pprint  “Please  hit  'return'  to  continue.”) 

(read-line) 

(terpri) 

(main-menu)) 

((equslp  (car  answer)  '(Parts  Identification!) 

(terpri) 

(pprint  "The  Parts  Identification  facility  is  not  yet  available.") 
(pprint  "Please  hit  'return'  to  continue.") 

(read-line) 


-  •  . 


W  -  V^-\V  "V  «  V  k>  .'VVW  W  V*.  V3  ■?  *~1  r"  *--  ------  •.  -  J  V.  • 

i . . 
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*• 

; 

> 

(terpri) 

(main-menu)) 

((equalp  (car  anawer)  'IComponent  Conatruction I ) 
(conat ruction-menu)) 

(T  nil))) 


[• 

: 

■ 

c 

1 


I 
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;  Marne:  conatruction-menu 

;  Proceaaing:  Ihia  routine  diaplaya  the  menu  for  conatructa  and  diapiaya  the 
;  aenu  for  the  Component  Conatruction  faciltiy  of  the  AKPEE  Syatea. 

;  Output:  The  menu  ia  displayed  _ _ 

(defun  conatruction-menu  () 

(call-out  era ae -page  1  1) 

(aetq  path  '(IComponent  Conatructionl)) 

(aetq  menu  liat  (add  numbere  '((IComponent  Cenerationl) 

(IComponent  Begenerationl ))» 


(aetq  anawer  (menu_read  path  nenu_liat  nil  nil)) 

(cond  ((equalp  (car  anawer)  'IComponent  Cenerationl) 

(part-cona true tor-menu ) ) 

((equalp  (car  anawer)  'IComponent  Begenerationl) 

(terpri)  .  ..  .. 

(pprint  "The  Component  Begencration  facility  ia  not  yet  available.  1 
( pprint  "Pleaee  hit  'return'  to  continue.”) 

(read-line) 

(terpri) 

(conatruction-menu)) 

(T  nil))) 


Name:  part-conatruc tor-menu  () 

Proceaaing:  Thia  routine  conatructa  and  diaplaya  a  menu  for  the 
conatructora  that  compriee  the  AKPEE  Syatem  Component  Generation  facility. 
Output:  The  menu  ia  diaplayed. 


(defun  part-conatruc tor-menu  () 

(call-out  eraae-page  1  1) 

(aetq  path  '(IComponent  Conatructora I )) 

(aetq  manu— liat  (add_ numbera  '((iFinite  State  Machinel)))) 
(aetq  anawer  (menu_read  path  menu_liat  nil  nil)) 

(cond  ((equalp  (ear  anawer)  'IFinite  State  Machinel) 


167 


-  ,  •  *'  .V  *- 


.•  ~  rn  r  • 


£ 


REFERENCES 


Lanergan,  Robert  G.,  and  Denis  K.  Dugan,  "A  Successful  Approach  to 
Managing,  Developing,  and  Maintaining  Software",  IEEE8?  Trends  and 
Applications:  Advances  In  Information  Technology,  1982. 

Lanergan,  Robert  G.,  and  Denis  K.  Dugan,  "Software  Engineering  with 
Reusable  Designs  and  Code",  IEEE  1981  Compcon  Fall,  pp  296-303. 

The  Hartford  Insurance  Group,  The  Productivity  Challenge,  March 

1982. 

The  Hartford  Insurance  Group,  The  Productivity  Challenge  II,  March 

1983. 


National  Bureau  of  Standards,  Software  Summary  for  Describing 
Computer  Programs  and  Automated  Data  Systems,  Federal  Information 
Processing  Standards  (FIPS)  Publication  30,  June  30,  1974. 

American  National  Standards  Institute,  American  National  Standard 
for  Computer  Program  Abstracts  (ANSI  X3.88-1981). 

Promotional  material  from  DACS 

NTIS,  A  Directory  of  Computer  Software,  National  Technical 
Information  Service,  Springfield,  Virginia,  1984. 

NTIS,  NTIS  Subject  Classification  (A  Guide  for  SRIM  Users), 
National  Technical  Information  Service,  May,  1980. 

IMSL,  IMSL  Library  Reference  Manual,  1979,  International 
Mathematical  and  Statistical  Library,  Houston,  TX 


Promotional  material  from  NAG,  Inc. 


ACM,  Collected  Algorithms  from  CACH,  ACM,  New  York,  New  York,  1980. 

Datapro  Research  Corporation,  Oatapro  Directory  of  Micro  Computer 
Software,  2  volumes,  Datapro  Research  Corporation,  Oelran,  New 
Jersey,  1984. 

International  Computer  Programs,  ICP  Software  Directory,  52nd 
edition,  7  volumes,  International  Computer  Programs,  Indianapolis, 
Indiana,  1984. 

Parker,  Robert  A.,  Kathryn  L.  Henlnger,  David  L.  Parnas,  and  John  Z 
Shore,  Abstract  Interface  Specifications  of  the  A-7E  Interface 
Module,  Information  Systems  Processing  Branch,  Communications 
Division,  Naval  Research  Lab,  Nov.  20,  1980. 

Clements,  Paul  C.,  R.  Alan  Parker,  David  L.  Parnas,  and  John  Shore, 
A  Standard  Organization  for  Specifying  Abstract  Interfaces,  Naval 
Research  Laboratory,  Computer  Sciences  and  Systems  Branch, 
Information  Technology  Division,  June  14,  1984. 

Neighbors,  J.M.,  Software  Construction  Using  Components,  Ph.D. 
Dissertation,  Department  of  Information  and  Computer  Science,  Unlv. 
of  California,  Irvine,  Technical  Report  160,  1980. 

Oe  Roze,  Barry  C.,  Defense  System  Software  Management  Plan, 

Defense  Technical  Information  Center,  Oefense  Logistics  Agency, 
March  1976. 

Jones,  Capers,  "A  Survey  of  Programming  Design  and  Specification 
Techniques",  Proceedings  of  Conference  on  Specifications  of 
Reliable  Software,  1979. 


[20]  Blermann,  Alan  W.,  "Approaches  to  Automatic  Programming",  Advances 
In  Computer  Science,  vol.  15,  Morris  Rublnoff  and  Marshall  C. 

Yovlts,  eds..  Academic  Press,  1976. 

[21]  Brown,  John  R.,  "Getting  Better  Software  Cheaper  and  Quicker", 
Practical  Strategies  for  Developing  Large  Software  Systems,  Ellis 
Horowitz,  ed.,  Addlson-Wesley,  1975. 

[22]  Prywes,  Noah  S.,  "Automatic  Generation  of  Computer  Programs", 
Advances  In  Computers,  vol.  16,  Morris  Rublnoff  and  Marshall  C. 
Yovlts,  eds.,  Academic  Press,  1977. 

i 

[23]  Barr,  Avron  and  Edward  A.  Felgenbaum  (eds.).  The  Handbook  of 
Artificial  Intelligence,  vol.  2,  William  Kaufmann,  Inc.,  Los  Altos, 
CA  1982. 

[24]  Rawlings,  Terry  L.,  "A  Technological  Approach  to  Automating  Software 
Maintenance",  Proceedings  of  the  1st  Software  Maintenance 
Workshop,  IEEE,  1983. 

[25]  Rawlings,  Terrv  L.,  "A  Discussion  of  Knowledge  Representation  within 
the  DARTS  Technology",  Proceedings  of  the  17th  Aslmolar  Conference 
on  Circuits,  Systems,  and  Computers,  IEEE,  1984. 

[26]  McFarland,  C.  and  Rawlings,  T.,  "DARTS  -  A  Software  Manufacturing 
Technology",  Proceedings  of  the  AIAA  21st  Aerospace  Sciences 
Meeting,  Jan.  10-13,  1983,  Reno,  Nevada. 

[27]  Promotional  material  from  HOS 

[28]  Hamilton,  M.  and  S.  Zeldin,  "The  Functional  Life  Cycle  Model  and  Its 
Automation:  USE. IT",  The  Journal  of  Systems  and  Software,  vol  3, 
1983. 


[29]  Hendrix,  Gary  G.  and  Earl  0.  Sacerdotl ,  “Natural  Language  Processing 
-  The  Field  In  Perspective",  Byte,  Sept.  1981. 

[30]  8arr,  Avron  and  Edward  A.  Felgenbaum  (eds.).  The  Handbook  of 
Artificial  Intelligence,  vol .  1,  William  Kaufmann,  Inc.,  Los  Altos, 
Ca.,  1981. 

[31]  Stoegerer,  J.K.,  "A  Comprehensive  Approach  to  Specification 
Languages",  The  Australian  Computer  Journal,  vol.  16,  no.  1, 

February  1984. 

[32]  McDonnell  Oouglas  Astronautics  Company,  "SEP  2.205:  Software 
Requirements  Engineering  Tools",  Software  Engineering  Practices 
Manual,  McDonnell  Oouglas  Corporation,  January,  1982. 

[33]  Prywes,  Noah  and  Amir  Pnuell,  "Compilation  of  Nonprocedural 
Specifications  Into  Computer  Programs",  IEEE  Transactions  on 
Software  Engineering,  vol.  SE-9,  no.  3,  May,  1983. 

[34]  McDonnell  Douglas  Astronautics  Company,  Ada  Oeslgn  Language  (ADL) 
Reference  Manual,  McDonnell  Douglas  Corporation,  1983. 

[35]  Using  Ada  (TM)  as  a  Oeslgn  Language,  Oraft  Version  2.2,  IEEE 
Working  Group  on  "Ada  as  a  Program  Design  Language",  July  31,  1984. 

[36]  81ermann,  Alan  W.,  etal  (eds.),  Automatic  Program  Construction 
Techniques,  Macmllllan  Publishing,  1984. 

[37]  MIT  Laboratory  for  Computer  Science,  Laboratory  for  Computer 
Science  Progress  Report,  Massachusetts  Institute  of  Technology, 

July  1982-June  1983./ 


172 


■3 


[38]  Booch,  Grady,  Software  Engineering  with  Ada,  The  Benjamin/Cummings 
Publishing  Company,  Inc.,  1983. 

[39]  Buhr,  Raymond,  System  Design  with  Ada,  Prentice-Hall,  1984. 

[40]  Partsch,  H.,  and  R.  Stelnbruggen,  "Program  Transformation  Systems", 
ACM  Computing  Surveys,  vol .  15,  no.  3,  Sept.,  1983. 

[41]  Rich,  Charles,  and  Howard  E.  Shrobe,  "Design  of  a  Programmer's 
Apprentice",  Artificial  Intelligence:  An  MIT  Perspective,  vol.  1, 
Patrick  Henry  Winston  and  Richard  Henry  Brown,  eds.,  The  MIT  Press, 
Cambridge.  MA,  1979. 

[42]  Green,  Cordell,  et  al ,  Report  on  a  Knowledge-Based  Software 
Assistant,  Kestrel  Institute,  June,  1983. 

[43]  Osborn,  S.L.,  In  a  review  of  "SOFSPEC:  A  Pragmatic  Approach  to 
Automated  Specification  Verification",  Erika  Nyarl  and  Harry  M. 
Sneed,  Computing  Reviews,  vol.  25,  no.  10,  p.  465. 

[44]  McDonnell  Douglas  Astronautics  Co.,  Ada  Missile  Parts  Engineering 
Expert  System  Software  Requirements  Specification,  Final, 

September,  1985. 

[45]  McDonnell  Douglas  Astronautics  Co.,  Ada  Missile  Parts  Engineering 
Expert  System  Software  Top-Level  Design  Document,  Final,  September, 
1985. 

TH 

[46]  Inference  Corporation,  ART  Reference  Manual,  April,  1985. 


TM 

[47]  Clayton,  Bruce  D.,  ART  Programming  Primer,  Inference  Corp., 
April,  1985. 

TH 

[48]  Clayton,  8ruce  D.,  ART  Programming  Tutorial,  Volume  1: 

Elementary  ART  Programming,  Inference  Corp.,  March,  1985. 

TM 

[49]  Clayton,  Bruce  D.,  ART  Programming  Tutorial,  Volume  2:  A  first 
Look  at  Viewpoints,  Inference  Corp.,  March,  1985. 

[50]  Dym,  Clive  M.,  "Expert  Systems:  New  Approaches  to  Computer-Aided 
Engineering*  Xerox  PARC,  April,  1984. 

[51]  "NISO  to  Introduce  Software  Numbering  System",  Advanced  Technology 
Libraries,  vol.13,  no.  9,  Sept.  1984,  Knowledge  Industries 
Publications,  Inc. 


174 


INITIAL  DISTRIBUTION 


DTIC-DDAC 

2 

NASA  (CODE  RC) 

1 

AUL/LSE 

1 

NSA 

1 

FTD/SDNF 

1 

NTSC/CODE  251 

1 

HQ  USAFE/INATW 

1 

AD/XRB 

1 

AFWAL/FI ES/SURVI AC 

1 

LOCKHEED  (DR  SURY) 

1 

AFATL/DOIL 

2 

HUGHES  (MR  BARDIN) 

1 

AFATL/CC 

1 

IBM  (MS  VESPER) 

1 

AFCSA/SAMI 

1 

RAYTHEON  (WILLMAN) 

1 

AFATL/CCN 

1 

SOFTECH  INC  (MS  BRAUN) 

1 

AFATL/FXG 

10 

MITRE  CORP  (MR  SYLVESTER) 

1 

ASD/RWX 

1 

AEROSPACE  CORP  (MR  HOGAN) 

1 

SPAWAr.  (814AB  NC  #1) 

1 

TEXAS  INSTRUMENTS  (MR  FOREMAN) 

1 

SPAWAR  (CODE  613) 

1 

RATIONAL  (MR  BOOCH) 

1 

NRL  (CODE  5150) 

1 

ROCKWELL  INTERNATIONAL  (MR  GRIFFIN] 

1  1 

ASD/XRX 

1 

MITRE  CORP  (MS  CLAPP) 

1 

AFWAL/AAA-2 

1 

NOSC  (CODE  423) 

1 

HQ  AFSC/PLR 

3 

GENERAL  DYNAMICS  (MR  MURRAY) 

1 

INST  OF  DEFENSE  ANALYSES 

5 

HONEYWELL  INC  (MS  GIDDINGS) 

1 

STARS  JOINT  PROGRAM  OFFICE 

1 

HONEYWELL  INC  (DR  FRANKOWSKI) 

1 

USA  MATERIEL  CMD/AMCDE- 

■SB 

1 

HUGHES  DEFENSE  SYS  DIV  (S.Y.  WONG) 

1 

NAVAL  SEA  SYS  CMD  (SEA  61R2) 

1 

NOSC  (MR  WASILAUSKI) 

1 

NAVAL  AIR  DEVELOPMENT  CTR  (CODE  50C) 

1 

NAC  (N) 

1 

BMDATC 

1 

TASC  (MR  SERNA) 

1 

NSWC/CODE  N20- 

1 

MARTIN  MARIETTA  (MR  CUDDIE) 

1 

NAVAL  UNDERSEA  SYS  CTR 

(CODE  3511) 

1 

TASC  (DR  CRAWFORD) 

2 

NOSC/CODE  423 

1 

SYSCON  CORP  (DR  BRINTZINHOFF) 

1 

AFWAL/AAAF-2 

1 

ADA  TRAINING  SECTION 

1 

USA  EPG/STEEP-MT-DA 

1 

COMPUTER  SCI  CORP  (MR  FRITZ) 

1 

AFSC/DLA 

1 

LINKABIT  (MR  SIMON) 

1 

USA  MSL  CMD/AMSMI -OAT 

1 

RAYTHEON  (MR  GINGERICH ) 

1 

SPAWAR  (CODE  06  NC  #1) 

1 

UNIVERSITY  OF  COLORADO 

1 

ASD/EN 

1 

MCDONNELL  AIRCRAFT  (MR  MCTIGUE) 

1 

AD/ENE 

1 

HUGHES  AIRCRAFT  (MR  NOBLE) 

1 

SD/ALR 

1 

GENERAL  DYNAMICS  (MR  PRZYBYLINSKI ) 

1 

RADC/COEE 

2 

AJPO  (MS  CASTOR) 

1 

NRL/CODE  7590 

1 

NWC  (CODE  3922) 

1 

AFSC/SD2D 

1 

NAVAIRSYSCOM  HQS 

1 

HQ  USAF/RDPV 

1 

ASD/ENASF 

1 

AD/ENSM 

1 

ASD/ENA 

5 

BMO/ENBE 

1 

UNIVERSITY  OF  TEXAS 

1 

ESD/ALS 

1 

MARTIN  MARIETTA  (MR  SORONDO) 

1 

ESD/ALSE 

2 

MCDONNELL  DOUGLAS  (DR  MCNICHOLL) 

2 

AJPO 

1 

GENERAL  DYNAMICS  (MR  SCHNELKER) 

1 

AFATL/AS 

1 

TRW  (MR  SHUGERMAN) 

1 

AFATL/SA 

1 

RATIONAL  (MR  HAKE) 

1 

AD/XP. 

1 

WESTINGHOUSE  (MR  GREGORY) 

2 

;::s  jpmo/adt 

1 

GENERAL  DYNAMICS  (DR  TABER) 

1 

AFWAL/AAAF 

1 

BOEING  COMMERCIAL  AIRPLANE  CO 

1 

INITIAL  DISTRIBUTION  (CONTINUED) 


ROCKWELL  INTERNATIONAL  (MIKULSKI)  1 
BOEING  AEROSPACE  (MR  HADLEY)  1 
IBM  (MR  MCCAIN)  1 
FSU  (DR  BAKER)  1 
AEROSPACE  CORP  (MR  LUBOFSKY)  1 
DATA  GENERAL  (MR  DAMASHEK)  1 
SDC  (MR  HERMANN)  1 
WINTEC  (MR  CONNEL)  1 
NORTHROP  (MR  OHLSEN)  1 
ARC  (MR  ROBERSON)  1 
GRC  (DR  ALBRITTON)  1 
AFWL/NTSAC  1 
USA  MSL  CMD/SCI  INFO  CTR  1 
NSWC/TECH  LIB  1 
NWC  (CODE  343)  1 
OO-NAVAL  RESEARCH  (CODE  784DL)  1 
NAVAL  POSTGRAD  SCHOOL  (CODE  1424)  1 
DEFENSE  COMMUNICATIONS  AGENCY  1 
NASA  AMES  RESEARCH  CTR  (CHAPMAN)  1 
NASA  LANGLEY  RESEARCH  CTR  (MOTLEY)  2 
RAND  CORP/AFELM  1 
AVCO  SYS  DIV/RESEARCH  LIB  1 
AVCO-EVERETT  RES  LAB/TECH  LIB  1 
FAIRCHILD  IND/INFO  CTR  1 
GENERAL  DYNAMICS,  CONVAIR  DIV  1 
GENERAL  DYNAMICS,  FT  WORTH  DIV  1 
HONEYWELL/TECH  LIB  1 
HUGHES  AIRCRAFT/TECH  LIB  1 
HUGHES  AIRCRAFT/MSL  SYS  GP/TECH  LIB  1 
LOCKHEED/TECH  LIB  1 
LOCKHEED/TECH  INFO  CTR  1 
MARTIN  MARIETTA/TECH  LIB  1 
MCDONNELL  DOUGLAS/TECH  LIB  1 
MCDONNELL  DOUGLAS/LIB  SVCS  1 
NORTHROP  CORP/AIRCRAFT  DIV  1 
RAYTHEON/TECH  LIB  1 
VOUGHT  CORP/LIB  1 
SDC  (MR  MILLAR)  1 
INTERMETRICS  (MR  ZIMMERMANN)  1 
ROCKWELL/TECH  INFO  1 
TRW  (MR  MUNGLE)  1 
AT&T  (MR  MAY)  1 
AVCO  SYS  TEXTRON  (MR  SOHN)  1 
BOEING  ELECTRONICS  (MR  MEDAN)  1 
USA  CECOM/DRSEL-TCS-MCF  1 
USA  CECOM/DRSEL-TCS-ADA  1 
UNIVERSITY  OF  WASHINGTON  1 
AFATL/GRC  1 
USA-ARDC  1 


ROCKWELL  (MS  KIM)  1 

SCIENCE  APPLICATIONS  INTERNATIONAL 
(MR  STUTZKE )  1 

NSWC  (U-33)  1 

COMPUTER  SOFTWARE  &  SYSTEMS  1 

GRUMMAN  DATA  SYSTEMS  (MR  MARKMAN)  1 
AFWAL/FIGL  1 

AFWAL/FI GX  1 

AFWAL/AARI-1  1 

EMERSON  ELECTRIC  (MR  BYRNES)  1 

TASC  (MR  JAZMINSKI)  1 

E-SYSTEMS  (MR  SNODGRASS)  1 

NTSC  (CODE  742)  1 

UNIVERSITY  OF  ALABAMA  1 

MCDONNELL  DOUGLAS  (MR  VILLACHICA)  1 
SANDERS  ASSOCIATES  (MR  FRY)  1 

AFSC/PLR  1 

AFSC/DLA  1 

WESTINGHOUSE  (MR  SQUIRE)  1 

NAVAIR  SYSCOM  (AIR  54662)  1 

BOEING  AEROSPACE  (MR  BOWEN)  1 

GOULD  INC  (DR  ARORA)  1 

LOCKHEED  (MR  PINCUS)  1 

INTERMETRICS  (MR  BROIDO)  1 

GENERAL  ELECTRIC  (MS  MICKEL)  1 

HUGHES  AIRCRAFT  (DR  HUANG)  1 

SYSTEMS  DEVELOPMENT  (MR  SIMOS)  1 

GENERAL  DYNAMICS  (MR  WARNER)  1 

CARNEGI E-MELLON  UNIVERSITY  1 

COMPUTER  TECH  ASSOCIATES  (HEYLIGER)  1 
NORTHROP  CORP  (MR  SWAN)  1 

CNI  SOFTWARE  (SINGER  KEARFOTT  DIV)  1 
LOCKHEED  (MR  COHEN)  1 

MCDONNELL  DOUGLAS  (SANDY  COHEN)  2 

DRAPER  LABORATORY  (MR  DAVID)  1 

DRAPER  LABORATORY  (DR  DEWOLF)  1 

GOULD  INC  (MR  WILLIS)  1 

ADVANCED  TECHNOLOGY  (MR  COOPER)  1 

HQ  USAF/RDST  1 

AFPRO/EN  1 

AFPRO/TRW/EPP  1 

LOCKHEED  (MR  DORFMAN)  1 

HONEYWELL  (MR  LANE)  1 

SPERRY  A&MG  (MR  ROSS)  1 

UNITED  TECHNOLOGIES  (STOLZENTHALER)l 
LTV  AEROSPACE  &  DEFENSE  1 

EL66  B  4610  (MR  FREEMAN)  1 


SYSTEMS  DEVELOPMENT  CORP  (ATCHLEY)  1 


INITIAL  DISTRIBUTION  (CONCLUDED) 


ROCKWELL  (DILLHUNT)  1 
IBM  FED  SYSTEMS  DIV  (MR  ANGIER)  1 
JET  PROPULSION  LAB  (MR  KRASNER)  1 
MARTIN  MARIETTA  ORLANDO  AEROSPACE  1 
GENERAL  ELECTRIC  (MR  DELLEN)  1 
AFWAL/PDFIC  1 
LOCKHEED  (READY)  1 
BOEING  AEROSPACE  (MR  DOE)  1 
FORD  AEROSPACE  (DR  FOX)  1 
LOCKHEED  SOFTWARE  TECH  CTR  (LYONS)  1 
I3M  (MR  BENESCH)  1 
MITRE  CORP  (MR  SHAPIRO)  1 
MITRE  CORP  (MR  MAGINNIS)  1 
GRUMMAN  AEROSPACE  (MR  POLOFSKY)  1 
MCDONNELL  DOUGLAS  (KAREN  L  SAYLE)  1 
MCDONNELL  DOUGLAS  (GLENN  P  LOVE)  1 
ROME  AIR  DEVELOPMENT  CTR  (CHRUSCI CKI )  1 
RAYTHEON  EQUIPMENT  DIV  (MS  SILLERS)  1 
AT&T  BELL  LABS  (MS  STETTER)  1 


177 

(The  reverse  of  this  page  is  blank) 


r 


inis  REPORT  HAS  BEEN  DELIMITED 
AND  CLEARED  FOR  PUBLIC  RELEASE 

UNDER  DOD  DIRECTIVE  5200,20  AND 

nu  RESTRICTIONS  ARE  IMPOSED  UPON 
ITS  USE  AND  DISCLOSURE, 

DISTRIBUTION  STATEMENT  A 

APPROVED  FOR  PUBLIC  RELEASE; 
DISTRIBUTION  UNLIMITED, 


ERRATA 

AFATL-TR-85-93 
VOLUMES  I,  II,  and  III 

COM3N  ADA® MISSILE  PACKAGES  (CAMP) 

FINAL  REPORT 

AIR  FORCE  ARMAMENT  LABORATORY 
E3LIN  AIR  FORCE  BASE,  FLORIDA 
32542-5434 

1.  CO  Form  1473: 

In  Block  16,  add  the  following: 

"Methodology  used  in  this  report  does  not  constitute  conputer 
software  as  defined  in  AFR  300-6." 

2.  This  errata  is  unclassified. 


Chief,  Technical  Reports  Section 


♦ 


<4 


SUPPLEMENTARY 


INFORMATION 


REPLY  TO 
.  ATTN  OF: 


MNOI 


DEPARTMENT  OF  THE  AIR  FORCE 

WRIGHT  LABORATORY  (AFSC) 

EGUN  AIR  FORCE  BASE,  FLORIDA,  32542-5434 

W^t/03  t 


13  Feb  92 


subject-  Removal  of  Distribution  Statement  and  Export-Control  Warning  Notices 


to-  Defense  Technical  Information  Center 
ATTN:  DTIC/HAR  (Mr  William  Bush) 

Bldg  5,  Cameron  Station 
Alexandria,  VA  22304-6145 

1.  The  following  technical  reports  have  been  approved  for  public  release  by 
the  local  Public  Affairs  Office  (copy  attached). 


Technical  Report  Number 

AD  Number 

1 .  88-18-Vol-4 

ADB 

120  251 

Z.  88-I8-V0I-5 

ADB 

120  252 

3*  88-I8-V0I-6 

ADB 

120  253 

-4.  88-25-Vol-l 

ADB 

120  309 

5.  88-25-Vol-2 

ADB 

120  310 

fc.  88-62-Vol-l 

ADB 

129  568 

n.  88-62-V01-2 

ADB 

129  569 

88-62-V01-3 

ADB 

129-570 

9*  85-93-Vol-l 

ADB 

102-654 

<0.  85-93-Vol-2 

ADB 

102-655 

M.  85-93-Vol-3 

ADB 

102-656 

\Z.  88-18-Vol-l 

ADB 

120  248 

15.  88-18-Vol-2 

ADB 

120  249 

\A.  88-18-Vol-7 

ADB 

120  254 

IS.  88-I8-V0I-8 

ADB 

120  255^ 

iU.  88-I8-V0I-9 

ADB 

120  256 

(7.  88-18-Vol-lO 

ADB 

120  257^ 

1  88-18-Vol-ll 

ADB 

120  258 

19. 88-18-Vol-12 

ADB 

120  259 

2.  If  you  have  any  questions  regarding  this  request  call* me  at  DSN  872-4620. 


ERRKTft 


1  Atch 

AFDTC/PA  Ltr,  dtd  30  Jan  92 


KPAimKMT  Of  THE  AM  FORCE 

HEADQUAJITEM  AM  FORCE  OCVELOMyKNT  TEST  CEHTER<AfaC) 
E<MM  AM  FORCE  BASE.  FIOMQA3Z8424000 


REPLY  TO 
ATTN  OF- 


PA  (Jim  Swinson,  882-3931) 
subject,  clearance  for  Public  Release 


30  January  1992 


to:  WL/MNA 


Hie  following  technical  reports  have  been  reviewed  and  are  approved  for 
public  release:  AFATL-TR-88-18  (Volumes  1  &  2) ,  AFATL-TRr 88-18  (Volumes 
4  thru  12),  AFATL-TR-88-25  (Volumes  1  &  2),  AFATL-TR-88-62  (Volutes  1  thru  3) 
and  AFA3Xr-TR-85-93  (Volumes  1  thru  3) . 


PRIBYLA,  Lt  Col, 
Chief  of  Public  Affairs 


AFOTO/PA  92-039 


